Tab Skips over some buttons in Dialogue Boxes

[jmwmusic]

Issue type

UI bug

Bug description

In many places in MuseScore 4 dialogs, the various buttons in the dialogs are not accessible using the standard navigation method pressing the Tab key. There are many examples, but the first a user will encounter is the New Score Wizard. Also: • Crash recovery dialog "The previous session quit unexpectedly", Tab only goes to the No button. • Update available, Tab only goes to the Update Now button. • Add bars dialog, Tab only goes to the OK button. • Preferences dialogs, Tab only goes to the OK button. • Confirm Quit dialog: Tab only goes to Don't save. • ... and many more examples.

one that many screen reader users have been confused by is the export dialogue box. Tab will get you to the main drop down to choose the export method, but pressing tab again after selecting the method jumps to the export button and the screen reader is completely unaware there were further options (such as compression for xml or not) that have been missed. They are left thinking MuseScore just doesn't do these things and so don't go looking for further instructions on how to do it as it is very unusual screen reading behaviour for all actionable items in a dialogue box not to be discoverable with the Tab key. in effect it makes these other items invisible like putting them in white text on a white background, they are there but not going to be noticed without taking an unusual action to look for them.

Compare the standard system File Open and File Save As dialogs.

Steps to reproduce

1. From the File menu choose New, or press Ctrl+N. The New Score Wizard appears.
2. Tab around the first page of the wizard. Notice that only the Cancel button can be accessed. This gives the misleading impression that the user has not completed the options in the page and cannot progress.
3. Repeat, but fill in options before tabbing around. It is the same, only the Cancel button gets focus with Tab.

Expected behaviour: Tab key should cycle through all the main controls in this and many other dialogs.

Actual behaviour: a combination of Tab and Arrows is required to reach some controls.

Screenshots/Screen recordings

No response

MuseScore Version

4.1

Regression

I don't know

Operating system

Windows 10 with NVDA

Additional context

No response

[MarcSabatella]

Note that this is by design, in general - MuseScore has adopted the modern hierarchical model with F6 / Tab / Cursor instead of just Tab. So you will need to get used to using all three methods in order to fully explore any given window. But that doesn’t mean there isn’t room for improvement. Probably there are some places where the hierarchy isn’t needed. There are a couple of other open issues regarding specific cases, like the New Score wizard.

[jmwmusic]

Yes I am aware that this is by design for many windows and panels to use the F6 system. That is why I have limited this to dialogue boxes. I know Edge, Word, etc are using the F6 and similar hierarchical design in some places, but it is I believe still non standard for dialogue boxes and without additional screen reader hints or wording definitely doesn't fall within guidelines for accessibility.

[paullovessearch]

I encountered this right away. New Score / Grand Staff / Next (Additional Score Information) / Click on Title / Enter a Title / TAB --> Proceeds to CANCEL

Continued presses of TAB then go to Key Signature, then back to Title - only those three controls are highlighted with the Tab key.

Basically, I expect to be able to enter the title, then hit TAB to enter the composer, but no! Seems very strange.

Oh, I see. I have to enter the down-arrow to sequence between boxes within a dialog box... hmmm....

Anyway, it does seem strange and non-intuitive. Every other form I've ever filled out would allow me to tab from Title to Composer and not just skip everything and go right to CANCEL.

And if you're tabbing through groups of controls, maybe it should go to DONE and not CANCEL?

Version OS: macOS 12.6, Arch.: x86_64, MuseScore version (64-bit): 4.1.1-232071203, revision: github-musescore-musescore-e4d1ddf

[msviolafangirl]

I concur with everything that has been said here. It's not just in the new score wizard, it's also in the preferences dialog among other places. You have to use both tab and arrow keys to navigate through the different controls of each dialog. I'm used to it by now, but I can see how this is unintuitive for a lot of new users. Hierarchical navigation is great in some situations, but not others. I found out that one of the google summer of code suggested ideas was to rectify this sort of issue, but it didn't happen yet, so I think this is something worth fixing in the foreseeable future. https://musescore.org/en/node/344439

[jrbowden]

I also agree: the hierarchical model using F6 should only apply when there are large numbers of items, or perhaps distinct panels - such as in the main score writing screen. For dialog boxes, it is very standard to use Tab to get to all controls. As @msviolafangirl said, I am mostly used to it now, but it does trip me up, and was very unintuitive when I started using MuseScore 4. Using a combination of Arrows and Tab will confuse many new users. Note also that the non-standard navigation has also forced a non-standard use for combo boxes (pull down lists). You have to press Space/Enter to open them and then use Arrows to select your option, then Space/Enter again. Ideally, you should just Arrow immediately and then Tab when the desired option is reached.

[iainhallam]

There are places in the UI where it seems on first look to be impossible to reach some fields with the keyboard. Select a note head, then open the appearance properties dropdown. "Leading space" is focused; the up and down arrows change the value, tab does nothing, left and right arrows move within the field, unless you've changed the value with the up and down arrows, in which case it seems the field container rather than the text is focused, when right arrow can move to the next field. F6 seems to do the same as tab, and Escape seems to play a role in making the focus be the field container rather than the text itself to activate the left and right arrows, but the minute you arrive in the next field, the text is focused again and the arrows are limited to moving through the text, rather than quickly moving through the fields, which seems to require Right, Esc, Right, Esc... on MuseScore 4.1.1.

"Keyboard users can use the Tab key or F6 to navigate between these UI regions via the keyboard. Within each region, navigation is performed with the arrow keys and Tab." (https://musescore.org/en/handbook/4/user-interface) doesn't seem to me to explain what's needed.

[shoogle]

I agree: we should make Tab stop on all controls like in a traditional app.

We can use Ctrl+Tab as the "go faster" shortcut to skip certain controls like Tab does now. The exception is in the score, where we will use Ctrl+Tab as the shortcut to switch between the score and the parts (i.e. to switch tab, as discussed in #23702). But if the focus isn't in the score (e.g. it's in the toolbars or palettes) then Ctrl+Tab is available for navigation.

[irwir]

When used in the standard way, Ctrl+Tab/ Ctrl+Shift+Tab in tabbed page control should go through available tabs. Redefinition of such shortcuts might be a very questionable practice. For example, currently it does not work for Paletts/Instruments... pane on the left of the main window.

[shoogle]

There's only a finite number of keys we can use.

I guess the Alt+direction combinations are available. We use these as next-element shortcuts in the score, but outside the score we could use Alt+direction to move to the nearest control in the given direction visually, rather than the next 'logical' control, which is what the directions do currently without the Alt modifier.

Some examples of where this would enable faster navigation:

• Mixer: Alt+Left and Alt+Right would move horizontally between columns (i.e. from one instrument to the next).
• Toolbars: Alt+Up and Alt+Down would move vertically from the toolbar above to the one below.
• Palettes: Alt+direction would allow movement in any direction.

There's also Page Up and Page Down, which are used in the score, but could be used for navigation in other contexts. For example, we could use these to move to the next or previous navigation panel, like Tab and Shift+Tab do now.

It appears we're already using Home and End to move to the start or end of the current panel, which makes sense. We could use Ctrl, Alt or Shift modifiers to make it do something else, like move to the start or end of the current navigation section. (Sections are things you navigate to with F6 and Shift+F6.)

[jrbowden]

Can I bring us back to the origin of this report: it is for navigation of dialog boxes, not the main window. @shoogle I'm not sure I like the idea of Alt+Arrows to move in a particular direction: screen readers seldom care about the layout of the controls. What is important is:

• Tab moves between all controls
• There are shortcut keys (e.g. Alt+N for a Next button, Alt+A for an Add button etc)
• Keys have their "usual" meaning, including arrow down on a combo box should move through the options
• When in a list, first letter navigation should select an item with that letter.

I agree that a different approach, with the arrows as we have it, is useful for the main window where there are many, many more controls. Here we're really talking about using arrows to move through the controls within a toolbar.

So please, let's not introduce Alt+arrows for navigation through controls, it's even more non-standard.

[irwir]

Can I bring us back to the origin of this report: it is for navigation of dialog boxes, not the main window.

Bringing back might be temporary, because Tab key could cause quite illogical jumps. For example, open any score and then open Mixer. In Mixer click on Metronome Volume and press a tab. Focus goes to Master Volume (not the most expected place, but this follows the current rules). Press Tab again. Instead of staying in Mixer, focus goes to Workspace pane in status bar.

[shoogle]

@jrbowden, thanks for the feedback! It's always good to get the RNIB perspective.

[this issue] is for navigation of dialog boxes, not the main window

The problem is we can't have different navigation in dialogs compared to the main windows. It would require a lot of effort to implement and the result wouldn't be very intuitive.

I agree that having Tab skip some things in the main window is quite useful, for example, in the toolbars and palettes. But it creates very unintuitive navigation in the Mixer and Properties panel.

My plan is for Tab to visit more things than it does now, but not every single UI element. For example, Tab would only stop on the first item in an item view, such as the first:

• Palette in the palette tree
• Menu item in a menu
• Radio button in a list of radio buttons
• Tab in a tab bar

Having reached the first item with the Tab key, arrow keys would be required to navigate to subsequent items in the view.

However, Tab would stop on all independent controls, such as every:

• Button
• Checkbox
• Slider
• Text field
• Dropdown combo box

You would still be able to navigate between buttons and checkboxes with the arrow keys, but now Tab would visit all of them too.

When it comes to sliders, text fields and dropdowns, the arrow keys would be used to interact with these controls, so you would need to use Tab to navigate away from them like in a traditional app.

Here we're really talking about using arrows to move through the controls within a toolbar.

You would still be able to do that. However, I'm not certain whether Tab should visit every button in the toolbar, like the arrow keys, or just the first button? If Tab only visits the first button then navigation is faster, but it makes the other buttons less discoverable for blind users. Also, it becomes tricky when the toolbar includes things that are not buttons, such as the text fields to set zoom percentage and playback timecode, which are not currently accessible.

My instinct here is to make Tab stop on all buttons in the toolbar, and provide another shortcut to enable fast skipping over the rest of the toolbar. This shortcut could be Page Down for example, which is Fn+Down arrow on laptop keyboards, so most users (who are on laptops) wouldn't even need to take their right hand off the arrow keys.

I'm not sure I like the idea of Alt+Arrows to move in a particular direction: screen readers seldom care about the layout of the controls. [...] It's even more non-standard

The primary method of navigation will always be arrow keys (without Alt modifier) and Tab. Every control needs to be accessible using those keys alone. Alt+direction wouldn't replace this, rather it would complement it, enabling advanced users to navigate to certain places a bit faster than they otherwise could. VoiceOver actually provides this form of navigation on macOS via VO+arrow (that's the VoiceOver modifier key plus a direction key).

[irwir]

If there is already F6 key for sections, why not let Tab key (also with modifiers) do just standard things?

[shoogle]

F6 isn't very discoverable. Also, it skips all of the toolbars except the first one. We need an intermediate shortcut that stops on the first button in each toolbar. Currently that's Tab, but I'm suggesting it should be Page Down, and Tab should visit all the buttons.

[jrbowden]

These are all interesting ideas, but can I make a plea that we stick to "standard" as far as possible. Standard = discoverable = familiar etc.

I think there really is a difference between the main window - which would include optional panels like the Mixer, and dialog boxes (such as Add bars, New Score Wizard, Update available, Confirm quit, etc, etc).

In the former case (main window, mixer etc) there are dozens of controls and the additional navigation is very beneficial. However, in dialogs, where there are limited numbers of controls, please let's do the standard thing with Tab if at all possible.

I think navigation of the Mixer really should be a separate topic. It is effectively a grid-like arrangement with various controls in each column. That's the kind of place where the geometric nagivation makes more sense.

By the way, ordinarily, toolbars aren't navigable at all with keyboard as you can't normally focus them ... now I'm not suggesting MuseScore should do the same as that, just a point of interest.

I trust this helps.

[jmwmusic]

I agree with jrbowden that the most important point is creating something that is standard and therefore automatic and intuitive to users without having to learn app specific navigation that requires additional documentation, training videos and even after that experienced users like myself just still keep hitting the wrong key on automatic and having to backtrack.

If at all possible dialogue boxes will behave in a completely standard way and this may be different to panels. in dialogue boxes every field, combo box and button should be discoverable with tab, it should not skip any. Combo boxes should automatically get focus when tabbing to them without having to press space to enter or exit, arrow keys navigate combo boxes and tabbing off them leaves the item that was last focussed selected. Buttons should have standard shortcuts such as Alt S Save, Alt C Close, Alt Y Yes, etc. Where a dialogue box has several different panes with tabs to move through them the tabs will navigate with left/right arrows and then pressing tab will jump into that panel. It is essential these say "tab" after there name so the user knows what they are dealing with.

The current system for panels from a user perspective can behave differently than dialogue boxes and is not currently so problematic for users. but, if this creates a big development difficulty having them different then please keep some basic principles of screen navigation in mind. 1. The most standard and intuitive approach is always best to avoid app specific learning. 2. If each item identifies what it is then users know what is expected behaviour from that item, just as you wouldn't make a radio button look like a tab or combo box as this is confusing. 3. Blind users rarely have a correct "picture" in their mind of the screen layout so try to think linearly unless something specifically identifies as a grid or table. 4. Think about physical movements for key strokes, keeping hands in one position is faster than using accelerants you have to shift for.

So, in this instance many will not bother using F6 but just tab because it is quicker than moving your hand. Closing unused windows will be common. Being able to hide more from the screen reader might be helpful. from the behaviours above if the different panels such as palette, properties, menu identified as "tab" as well as "radio button" it might make it clearer that they each open an underlying set of items (this is the current main confusion). Additional spoken info as hints as long as it is after the item so quick movement does not hear it would be welcome. e.g. "Properties Radio Button - Press space to switch to the properties window." Lists such as items in a palette should open and close when jumped to with tab without requiring space to open/close and first letter navigation in lists is also intuitive. Making Tab activate each item would for example only add one extra tab in the palettes area to jump over Add. Mixer, etc can be closed if you don't want to tab through it, but this really needs specific design as its own entity (nice to see channel instrument names have suddenly appeared, this is hugely helpful) and the current tabbing from one channel to the next and arrowing down through items is standard and expected, we would not want to see every item tabbable here.

Keeping in mind the linear nature of keybord navigation (rather than expecting a screen reader to understand the layout). There are currently a number of places where you have to use left/right arrow to move through options for an item, most of us have just never found these without being told as we move down through items. Ideally these would be changed to up/down arrows or all made tabbable. At the least they could again have additional speech added to prompt correct behaviour.

in general we don't use Pg Up/down to navigate or unusual combos of modifiers. In a browse mode navigation is usually done from letter such as H for heading, K for link, etc, but in dialogues and panels arrows, tab and shift and space/enter is pretty much it. Multiple presses of tab are usually faster than shifting to other keys and often we know these off by heart and just hit multiple times without pausing.

[shoogle]

Ok, let me list everything I agree with, subject to some caveats and exceptions:

1. Tab should visit every control in dialogs.
   • Exception: In item views, such as the instruments in the New Score dialog, Tab should only visit the first item (i.e. the first instrument) and the arrow keys must be used to reach subsequent items in the view.
2. Combo boxes and item views should provide first letter navigation (e.g. press F to jump to items beginning with 'F').
3. Up and Down arrow keys should change the value of a combo box without having to open it first.
4. Esc should not be required to navigate away from a text field or any other control in a dialog.
   • Exeption: Esc can be used to close pop-ups, such as the key signature popup in the New Score dialog.
5. Buttons in dialogs should have standard Alt+letter mnemonic access keys (e.g. Alt+Y for Yes, Alt+N for Next, etc.)
6. Tabs in a paginated interface should be spoken as "tab" rather than as "radio button" by the screen reader.
7. In a paginated interface, after focusing the desired tab with the arrow keys, you should press Tab to access its page.
   • Caveat: For performance reasons, we don't load the new page when its tab is focussed. Instead, you must press Space to select the tab, at which point its page is loaded, and then you can press Tab to access the page. Hopefully we can get screen readers to announce the "selected" or "not selected" state of the focussed tab.
8. Extended descriptions are welcome (e.g. "Key signature button - Press space to open the key signature popup.")
   • Caveat: Screen readers often ignore descriptions. Sometimes the best we can do is put the description in the name, so it says "Key signature - press space to open the key signature popup - button", which is far from ideal.

Hopefully we're all in agreement about what should happen in dialogs, which was the original topic of this issue.

I will create separate issues to discuss what should happen in the toolbars, Palettes, Mixer and Properties panel. When I create these issues, I'll post links to them here so you can follow along if you want to.

[jmwmusic]

Agree with all of that and look forward to seeing the thoughts on the new issues.

[jrbowden]

Can I just pick up on a couple of the items from @shoogle above:

1. Tab should visit every control in dialogs. Exception: In item views, such as the instruments in the New Score dialog, Tab should only visit the first item (i.e. the first instrument) and the arrow keys must be used to reach subsequent items in the view.

I agree: but there could be no "exception" here, if the list of items were a standard list or combo box. That would give the desired behaviour and be standard for navitation. ... of course, because I use a screen reader, I have no idea if visually these results are in fact like a list.

...

8. Extended descriptions are welcome (e.g. "Key signature button - Press space to open the key signature popup.")

Just to note that in many cases (including this one), no extended description is needed as the control is a button. Users know by default what to do with a button, so "press space to activate" is not necessary, because it is standard. In fact, certain screen readers can automatically add this "instruction" how to interact with a control.

Hopefully this slightly simplifies the task?

Many thanks again, this is all very encouraging.