I tried to search for similar topics in this forum, but couldn’t find one closely related. It seems the state of the keyboard accessibility support in the several dialogs in Dorico is not at the same level as I expect from a macOS application (don’t know the state of the Windows version as I don’t use it).
Some things I noticed:
Keyboard arrow keys not working in many lists in dialogs (i.e. Library Manager, several Library Options dialogs, but as a positive note the Edit Chord Diagrams dialog does support it).
Tab keys responding in unexpected ways and in some cases don’t work at all (i.e. the Project Info dialog: while the tab keys walk through the text box controls as expected, it’s impossible to tab to the flow list on the left, or the buttons at the bottom of it).
Some dialogs can’t be controlled by keyboard at all (i.e. Library Manager: please try to interact with the dialog using just the keyboard, I couldn’t aside from closing the dialog with the Esc key).
I like to see Dorico as a keyboard first application, with its many useful pop-overs and the Jump Bar ofcourse. Also it supports (almost) all commands to be bound to a key command. I like this very much.
Therefore I believe this should be consistently applied throughout the dialogs. It means that while having to navigate through dialogs and the music I don’t have to switch constantly between keyboard and mouse, which is a win for everyone of us.
We do aim to make Dorico navigable via the keyboard, but there are always some complications. Firstly, I assume you have enabled “full keyboard access” (whatever it’s called precisely these days, as this must be one of the more frequently renamed options in System Settings née System Preferences)? If not, then you won’t ever have keyboard access to anything other than direct input controls like fields for text and numbers.
We’re now using a mix of two different user interface technologies in Dorico: one of them has quite rich support for keyboard navigation out of the box without requiring us to do much work, the other has rather less (having been designed primarily for touch-based use cases). In the latter case (which includes complex dialogs like the Library Manager) there is certainly more for us to do in future.
You’re right, the Full keyboard access option is a requirement.
Thanks for the insights. It explains why some dialogs respond like expected and some others, like the Library Manager, which offer very little support for it.
Just out of interest: is there a way to do an educated guess which of the dialogs are using the more touch-friendly UI? I don’t really see the difference between these types by just looking at them.