Palette tree should be a single tabbable object

• Oct 27, 2019 - 05:54
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore

As discussed in https://musescore.org/en/node/296153 (see suggestion 5a).

Navigation within the tree should be done solely with the arrow keys. The user should be able to return to the searchbox at any time simply by pressing Shift+Tab once. Pressing Tab again should put the user back in the tree on the same item as they were on before they pressed Shift+Tab.

Current Desired

Currently all objects are tabbable. This includes all palettes, palette elements, expand/collapse arrows, three-dots buttons, and so on. navigating the entire palettes tree can easily involve pressing the Tab key 50 times or more. The search feature can help to reduce this number considerably, but the situation is still far from ideal.

Comments

• Oct 27, 2019 - 16:05

There are at least two reasons why this is currently implemented the current way.

First, all the other existing widgets (based on QWidget rather than QtQuick) implement a similar scheme of Tab navigation: Tab key goes through every single item in Inspector, every single button in toolbars and so on. It looks like the current palettes navigation behavior is more consistent with this scheme, although it sometimes behaves somewhat differently.

Second, it is currently not possible to reach More and three dots menu button with arrow keys as arrow keys navigation just uses what is implemented in ListView and GridView with manual handling of some keys to enable expanding/collapsing items with the keyboard. Maybe we could somehow force arrow keys navigation to include More button to its scope, but the three dots menu would still be unreachable with keyboard unless it has a special context menu key.

Also it is not really necessary to press Tab 50 times to get to "Add palettes" button. It looks like you have probably counted key presses after showing palette with F9 button, in this case the search box gets focused by default. If it is so, pressing Shift+Tab would focus "Add palettes" button with just one key press. This doesn't probably make it easy to discover this button using a screen reader but at least allows to use it relatively easily once it has been discovered. If tabbing though the entire MuseScore interface, then the first item that gets focused when the focus goes to palettes is exactly "Add palettes" button so multiple key presses are also not required.

Overall, the keyboard navigation in palettes is of course far from being perfect, but given the way in which Tab navigation is implemented in Qt by default, I am not sure whether the proposed behavior would be consistent with navigation over other MuseScore widgets (and which behavior would be consistent and convenient at all).

Reply

• Oct 27, 2019 - 18:06

@dmitrio95

> all the other existing widgets [...] implement a similar scheme of Tab navigation

True in most cases, but I would not consider accessibility in the rest of MuseScore to be an example that we should follow. Accessibility simply wasn't something that was taken into consideration when most of the GUI was designed. It's not anybody's fault; it's just a fact.

However, there are some parts of the GUI that have been designed specifically for accessibility, and these are the examples that we should be following. One such widget is the template chooser in the New Score Wizard, and it implements the behaviour I describe in this issue.

> it is currently not possible to reach More and three dots menu button with arrow keys

The More button should be reachable via arrow keys, as you suggested further down. I address the matter of the three-dots menu button in the full proposal (suggestion 5c). Basically, it should be reachable via the Tab key, but done in such a way that it appears (to a blind user) as though it is not part of the tree structure. In any case, I suspect these buttons will be of limited use to most blind users, as those users will simply use the Advanced workspace and search to narrow the results. Customisation offered by the three-dots menu is "nice to have" rather than essential.

> it is not really necessary to press Tab 50 times to get to "Add palettes" button [...] pressing Shift+Tab would focus "Add palettes" button with just one key press.

This is very true, but it's not quite the point I was trying to make. I am not concerned with how many keypresses it takes to get to the Add Palettes button. I am concerned with how many keypresses it takes to do a complete cycle of all the objects in the palette and get back to where you started. This matters when you are focussed on an object in the middle of the palette and want to return to the searchbox.

Reply

• Oct 30, 2019 - 02:22

@Marc Sabatella, thanks. I'm not sure how useful it is to have a special shortcut to go to the palette search given that F9 takes you there already (after a couple of presses). Maybe a shorcut that only works while you are in the palette (e.g. Alt+S or similar), with the key combination available for other uses outside the palette. RNIB have asked for contextual shortcuts like this in the past.

Anyway, I have actually made pretty good progress on the "single tabbable object" front so you can expect to see a PR soon. Fortunately QML is pretty flexible, so I have got 90% of the way there without having to make structural changes that would have been necessary in C++.

Reply

• Nov 7, 2019 - 11:17
Status PR created ⇒ fixed

Fixed in branch master, commit 1a6b2647f7

_fix #296154: Accessibility: Make palette tree a single Tab object

Navigation within the palette tree is now done almost entirely with the
arrow keys. This reduces the number of times the user has to press Tab
or Shift+Tab to leave the palette tree and navigate to other widgets. It
also enables the current item to be preserved on returning to the tree._

Reply

Fix version
3.3.1