1933309 - Arrow keys should select tabs and tab group labels in the tab strip

Status: NEW

(Firefox :: Tabbed Browser, task, P2)

Description

[Stephen Thompson [:sthompson]]

Bug 1921814 added tab group labels to the "multiselect" keyboard controls suite, but the QA and Accessibility teams raised concerns about keyboard navigation of the tab strip.

Anna from Accessibility gave an explicit recommendation in https://bugzilla.mozilla.org/show_bug.cgi?id=1921814#c13 which I'm paraphrasing here:

We should follow the spirit of the ARIA tabs pattern https://www.w3.org/WAI/ARIA/apg/patterns/tabs/ because users will expect to be able to use left and right arrow keys to select any item in the tab strip when the tab strip is in focus. There are other related keyboard interactions in the tab strip (cmd/ctrl + arrow keys to move the colored border around the tab strip, cmd/ctrl + shift + arrow keys to move the active tab) that have been in Firefox for some time, but there is no standard or ARIA recommendation for those interactions. It's acceptable to keep those related keyboard interactions as they are without accounting for the presence of tab group labels in the tab strip. However, it should be high priority that we provide users with the ability to use unmodified arrow keys to select both tabs and tab group labels when the tab strip is in focus.

Implementation notes:

The current behavior of the left/right arrow keys is to select/activate the next tab to the left/right.

If a tab is activated and in focus and next item in the tab strip to the left is a tab group label, then when the user presses the left arrow key, the tab group label should receive ARIA focus. The active tab will not change and the active tab will retain the DOM focus, but the tab group label will receive a colored border and be the target of aria-activedescendant so that screen readers read the tab group label as the selected item.

If a tab group label has ARIA focus and the next item in the tab strip to the left is not the active tab, then when the user presses the left arrow key, that tab will be activated and become the selected tab. The ARIA focus state should be cleared and screen readers will read the active tab as the selected item.

If a tab group label has ARIA focus and the next item in the tab strip to the left is the active tab, then when the user presses the left arrow key, the ARIA focus state will be cleared. Screen readers should read the active tab as the selected item, but this may benefit from manual testing to confirm.

Comment 1

[Stephen Thompson [:sthompson]]

You mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1921814#c13 that it would be helpful to users if when the tab group label receives focus, the tab group context menu is opened automatically.

I believe our current interaction model automatically focuses the tab group name input field upon opening the tab group context menu. If we automatically open the tab group context menu when the tab group label receives focus, would you expect the tab group label to retain focus but make the tab group context menu controls the "next" targets for the Tab key?

I looked around for any standard keyboard interaction that should perform the "context"/"right-click" action rather than a primary/"left-click" action, but I could not find anything. I found accessibility tools for using the keyboard to apply right-click input to the location of the mouse pointer, but that does not work for applying right-click input to an element that has DOM focus.

Our tab group labels currently have a primary action of expand/collapse and a secondary action of opening the tab group menu. We are allowing Enter/Space to expand/collapse the tab group. The menu button pattern https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/ also fits our use cases for tab group labels, but that pattern expects Enter/Space to open the menu.

Comment 2

[Stephen Thompson [:sthompson]]

Please see the above comment. Sorry for missing the needinfo when I posted it.