Arrow keys should select tabs and tab group labels in the tab strip
Categories
(Firefox :: Tabbed Browser, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox136 | --- | fixed |
People
(Reporter: sthompson, Assigned: sthompson)
References
(Blocks 2 open bugs)
Details
(Keywords: access, Whiteboard: [fidefe-tabgrps-tabbrowser])
Attachments
(1 file)
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.
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
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.
| Assignee | ||
Comment 2•1 year ago
|
||
Please see the above comment. Sorry for missing the needinfo when I posted it.
Updated•1 year ago
|
Comment 3•1 year ago
|
||
keeping the NI - I'd like to do a user testing/feedback session to clarify the possible behaviors for tab group label regarding activating it vs opening a menu with keyboard in a Fable user testing session.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
Currently, when the tab strip is in focus, pressing the arrow keys currently switches the active tab only. With this change, pressing the arrow keys will continue to switch the active tab when the adjacent item in the tab strip is a tab, but tab group labels will also receive keyboard focus if they happen to the adjacent items in the tab strip. Now, pressing left/right allows the user to "select" each tab or tab group label in the tab strip.
Comment 6•1 year ago
|
||
| bugherder | ||
| Assignee | ||
Updated•1 year ago
|
Comment 8•1 year ago
|
||
Confirmed the tab group label is focusable with arrow keys from the tablist. Thank you for the fix, Stephen!
Description
•