Make sidebar switcher keyboard accessible
Categories
(Firefox :: Keyboard Navigation, defect, P3)
Tracking
()
People
(Reporter: rfeeley, Assigned: ayeddi)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file)
Bug 1532282 - Make sidebar switcher menu to be PanelMultiView for its accessibility. r=Jamie,mconley
48 bytes,
text/x-phabricator-request
|
Details | Review |
STEPS TO REPRODUCE
- Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)
EXPECTED RESULTS
- User can shift-tab to give the switcher focus, hit enter to open menu, then navigate with arrow keys, and enter again to select a different sidebar
- User can simply arrow key navigate to select different options and enter to select
- All sidebars, including Synced Tabs, which is not XUL, support this.
ACTUAL RESULTS
- Shift-tab does not give sidebar switcher focus, and it appears that it is not keyboard accessible in any way
Comment 1•6 years ago
|
||
Marking this a P3. I'm surprised it wasn't in the original spec.
Updated•6 years ago
|
Comment 2•6 years ago
|
||
(In reply to Ryan Feeley [:rfeeley] from comment #0)
- Sidebar switcher has keyboard focus (with focus ring)
I don't think this is ideal. IMO, when a user hits control+b (which is for the Bookmarks sidebar specifically), they're probably interested in their bookmarks. Yes, we should be able to switch sidebars, but I don't think that should take initial focus.
- Shift-tab does not give sidebar switcher focus
If I hit control+b and shift+tab, it focuses the Close sidebar button. If I hit shift+tab again, that focuses the sidebar switcher button. Is this different on your system... or perhaps there's just no focus ring? (I'm using a screen reader, so I perceive focus regardless of focus ring.) What do you see when you shift+tab twice from the Bookmarks search box?
- User can hit enter to open menu and then navigate with arrow keys, and enter again to select an option
- User can simply arrow key navigate to select different options and enter to select
Assuming agreement on the above, this is the work that needs to be done here. Pressing enter/space on the switcher button does activate it, but you can't use keyboard navigation from there.
I also think we need to do something better for a11y labelling/semantics here. That button is just labelled "Bookmarks" with a role of button, which gives absolutely no indication that it allows you to switch to other views. How is this "switching" part indicated visually (before you open it)?
Reporter | ||
Comment 3•6 years ago
|
||
when a user hits control+b (which is for the Bookmarks sidebar specifically), they're probably interested in their bookmarks. Yes, we should be able to switch sidebars, but I don't think that should take initial focus.
Currently for bookmarks, history and synced tabs the search box takes focus.
My bias: I worked on Synced Tabs and Notes, which require the sidebar to function. During the development of these features it became clear that the namespace for keyboard shortcuts is over populated. Meaning, the ⌘B is the best keyboard shortcut to open the sidebar. Using the toolbar is awkward, and getting easy access to Notes is imperative. The keyboard shortcut for Notes is terrible, even if you don't have a conflicting extension installed.
If we make it easier for users to open the sidebar and switch to their desired sidebar with the keyboard, it might increase adoption of the sidebar.
So it comes down to the choosing to priorities searching the current sidebar versus the switching to another one.
I'm not a keyboard a11y expert, but we have some in our office so I'll ask.
Comment 4•6 years ago
|
||
(In reply to Ryan Feeley [:rfeeley] from comment #3)
If we make it easier for users to open the sidebar and switch to their desired sidebar with the keyboard, it might increase adoption of the sidebar.
That's a fair argument. However, control+b is currently explicitly the shortcut for the Bookmarks sidebar. We could change that, of course, but we need to be deliberate about that; control+b is then the "sidebar" key, not the "bookmarks sidebar" key. (Remember, we also have control+h for the history sidebar.)
Even if we did this, it's still not as efficient as it could be. If you really want fast sidebar access, the key should open the sidebar switcher, not just focus the button to open it. That way, you could, for example, hit control+b then n for notes, control+b then b for bookmarks, etc. All future sidebars would benefit from this. IMO, we should consider this two-key approach more often for lesser used functions instead of continuing to clutter our key map. I've proposed a similar argument for Dev Tools, which currently uses an obscene number of keyboard shortcuts.
Reporter | ||
Comment 5•6 years ago
|
||
On a Mac in the Finder Option-⌘-S opens the siderbar, but in Safari the sidebar is Shift-⌘-L. So odd.
Perhaps I'm digressing and should rewrite this bug to just deal with the lack of keyboard accessibility in the sidebar switcher?
Comment 6•6 years ago
|
||
(In reply to Ryan Feeley [:rfeeley] from comment #5)
On a Mac in the Finder Option-⌘-S opens the siderbar, but in Safari the sidebar is Shift-⌘-L. So odd.
Perhaps I'm digressing and should rewrite this bug to just deal with the lack of keyboard accessibility in the sidebar switcher?
I think your other ideas here are valuable. I'd love, however, to have one bug that's "fix the inaccessible selector" and if this is it, great. If not, I can clone this bug to create that bug.
Reporter | ||
Comment 7•6 years ago
|
||
Updated to remove mention on making the switcher focused by default. Perhaps will follow up in another bug (which requires further debate)
Comment 8•6 years ago
|
||
Ug. This doesn't use PanelMultiView, so we'll need yet another piece of custom key nav code to make this work as desired.
Reporter | ||
Comment 9•5 years ago
|
||
Weirdly we realized that the switcher and close icon ARE keyboard accessible but that they don't show focus, so I created this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1616324
Comment 10•5 years ago
|
||
(In reply to Ryan Feeley [:rfeeley] from comment #9)
Weirdly we realized that the switcher and close icon ARE keyboard accessible
If we're just talking about the button to open the switcher, this might be so. However, once you open the switcher, you can't use the keyboard to actually select a side bar. IMO, this shouldn't be closed... or do you want a separate bug filed for the actual dropdown?
Comment 11•5 years ago
|
||
Testing on Windows in case that's relevant; maybe this works on some other platform(s).
Reporter | ||
Comment 12•5 years ago
|
||
However, once you open the switcher, you can't use the keyboard to actually select a side bar. IMO, this shouldn't be closed... or do you want a separate bug filed for the actual dropdown?
You are right, you can't select one. This bug still applies. Re-opening.
Updated•5 years ago
|
Comment 13•5 years ago
|
||
From MarcoZ:
It doesn't even indicate that there's a dropdown there. It just says "Bookmarks button" or "History button", or whichever is selected. Hitting Space will put focus into limbo land. And it will open the dropdown without focusing it. No DOM focus or such.
Comment 14•5 years ago
|
||
Any chance of just updating this to use PanelMultiView? That would give you keyboard navigation "for free".
Comment 15•5 years ago
|
||
(In reply to James Teh [:Jamie] from comment #14)
Any chance of just updating this to use PanelMultiView? That would give you keyboard navigation "for free".
It probably works to wrap #sidebarMenu-popup's children with a <panelmultiview>
and <panelview>
, but it seems a bit strange when the panel only has a single view. Gijs knows this code better than me, so maybe he has a more informed opinion :)
Comment 16•5 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #15)
it seems a bit strange when the panel only has a single view
We do this when opening PanelUI-based views on their own, e.g. when showing a panel for the developer button. So it's not that strange.
I'm not sure if it's really as simple as you describe, I imagine we'd want to review the CSS to avoid duplication and/or adverse effects, and we may need to check what handlers the panelmultiview stuff implies, too. I also don't know if just adding the nodes would be sufficient here.
Updated•3 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 17•2 years ago
|
||
Changing a panel for the sidebar menu popup to utilize PanelMultiView component that provides most of the panel's a11y out-of-the-box, as well as adding some additional properties to provide more information to AT.
TODO:
- add/update tests
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 18•2 years ago
|
||
(In reply to Ryan Feeley [:rfeeley] from comment #0)
STEPS TO REPRODUCE
- Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)
EXPECTED RESULTS
- User can shift-tab to give the switcher focus, hit enter to open menu, then navigate with arrow keys, and enter again to select a different sidebar
- User can simply arrow key navigate to select different options and enter to select
- All sidebars, including Synced Tabs, which is not XUL, support this.
ACTUAL RESULTS
- Shift-tab does not give sidebar switcher focus, and it appears that it is not keyboard accessible in any way
The current state of the component in release:
- You can navigate to it with keyboard, both focused and hovered states are provided to the control, and you can activate it (with a
Space
alone though), but - the keyboard focus does not move to the menu, thus it is not testable if the menu items are accessible with a keyboard
- user cannot activate the menu with
Enter
The patch is under the review.
The updated STR and expected behavior is below:
STEPS TO REPRODUCE
- Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)
EXPECTED RESULTS
- User can
shift+tab
ortab
to give the switcher target focus.
1.1. Screen Reader would announce that the button is incollapsed
state and that the menu/dialog is opened (depending on a screen reader) - hit
enter
orspace
to open menu, Screen Reader would announce the update to the switcher button state -expanded
2.1. PressingEscape
would dismiss the sidebar switcher menu, collapse the switcher target button and return the keyboard focus to the currently opened sidebar - When the menu is opened, the keyboard focus is placed to the topmost menu item (
Bookmarks
) and the then navigate with arrow keys ortab
/shift+tab
- Press
enter
orspace
to select a focused sidebar - The selected sidebar is opened (i.e.
History
) and the focus is moved to the sidebar (i.e. to the search input on the History sidebar), the switcher panel menu is closed, the switcher target button iscollapsed
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Comment 20•2 years ago
|
||
Backed out for causing bc failures in browser_sidebar_switcher.js
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | browser/base/content/test/sidebar/browser_sidebar_switcher.js | The sidebar switcher target button is focused - {} == [object XULElement] - {"filename":"chrome://mochitests/content/browser/browser/base/content/test/sidebar/browser_sidebar_switcher.js","name":"testSidebarMenuKeyToggle","sourceId":892,"lineNumber":78,"columnNumber":10,"sourceLine":"","asyncCause":null,"asyncCaller":null,"caller":{"filename":"chrome://mochit
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 21•2 years ago
|
||
Comment 22•2 years ago
|
||
bugherder |
Assignee | ||
Updated•2 years ago
|
Comment 23•2 years ago
|
||
:ayeddi do you want to nominate this for 116 release notes?
Assignee | ||
Comment 24•2 years ago
|
||
Yes, I do. Thank you for the idea, :diannaS!
Release Note Request (optional, but appreciated)
[Why is this notable]: Sidebar switcher allows users to access Bookmarks, History and Synced Tabs panels easily and quickly switch between them. Now, keyboard users would be able to do it with ease too, with or without any assistive technology running, without needing to memorize keyboard shortcuts to access these panels.
[Affects Firefox for Android]: No
[Suggested wording]: Sidebar switcher allows users to access Bookmarks, History and Synced Tabs panels easily, quickly switch between them, move the sidebar to another side of the browser window, or close the sidebar. Now, keyboard users would be able to do it all with ease too, with or without any assistive technology running, without needing to memorize keyboard shortcuts to access these panels.
[Links (documentation, blog post, etc)]: N/a
Comment 25•1 year ago
|
||
Added to nightly and beta notes for fx116 https://www.mozilla.org/en-US/firefox/116.0beta/releasenotes/
Comment 26•1 year ago
|
||
(In reply to Anna Yeddi [:ayeddi] from comment #18)
The updated STR and expected behavior is below:
STEPS TO REPRODUCE
- Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)
EXPECTED RESULTS
- User can
shift+tab
ortab
to give the switcher target focus.
1.1. Screen Reader would announce that the button is incollapsed
state and that the menu/dialog is opened (depending on a screen reader)- hit
enter
orspace
to open menu, Screen Reader would announce the update to the switcher button state -expanded
2.1. PressingEscape
would dismiss the sidebar switcher menu, collapse the switcher target button and return the keyboard focus to the currently opened sidebar- When the menu is opened, the keyboard focus is placed to the topmost menu item (
Bookmarks
) and the then navigate with arrow keys ortab
/shift+tab
- Press
enter
orspace
to select a focused sidebar- The selected sidebar is opened (i.e.
History
) and the focus is moved to the sidebar (i.e. to the search input on the History sidebar), the switcher panel menu is closed, the switcher target button iscollapsed
I've verified the keyboard accessibility of the sidebar switcher button in the latest Firefox 116.0 on Windows 10 x64, with NVDA enabled, and macOS 13, with VoiceOver ON.
- I've noticed that the keyboard focus is not placed on topmost menu item (
Bookmarks
) and the user can not navigate usingtab
/shift+tab
inside the menu:
- no item is focused inside the sidebar switcher menu
tab
/shift+tab
will collapse the sidebar switcher menu
- Also pressing
space
doesn't select the focused sidebar
Should I reopen this bug or file a new one? Thanks.
Comment 27•1 year ago
|
||
(In reply to Ina Popescu, Desktop QA from comment #26)
(In reply to Anna Yeddi [:ayeddi] from comment #18)
The updated STR and expected behavior is below:
STEPS TO REPRODUCE
- Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)
EXPECTED RESULTS
- User can
shift+tab
ortab
to give the switcher target focus.
1.1. Screen Reader would announce that the button is incollapsed
state and that the menu/dialog is opened (depending on a screen reader)- hit
enter
orspace
to open menu, Screen Reader would announce the update to the switcher button state -expanded
2.1. PressingEscape
would dismiss the sidebar switcher menu, collapse the switcher target button and return the keyboard focus to the currently opened sidebar- When the menu is opened, the keyboard focus is placed to the topmost menu item (
Bookmarks
) and the then navigate with arrow keys ortab
/shift+tab
- Press
enter
orspace
to select a focused sidebar- The selected sidebar is opened (i.e.
History
) and the focus is moved to the sidebar (i.e. to the search input on the History sidebar), the switcher panel menu is closed, the switcher target button iscollapsed
I've verified the keyboard accessibility of the sidebar switcher button in the latest Firefox 116.0 on Windows 10 x64, with NVDA enabled, and macOS 13, with VoiceOver ON.
- I've noticed that the keyboard focus is not placed on topmost menu item (
Bookmarks
) and the user can not navigate usingtab
/shift+tab
inside the menu:
- no item is focused inside the sidebar switcher menu
tab
/shift+tab
will collapse the sidebar switcher menu
- Also pressing
space
doesn't select the focused sidebarShould I reopen this bug or file a new one? Thanks.
My understand is that all the things you noted are the expected behavior after bug 1835890 which landed after this one.
Comment 28•1 year ago
|
||
(In reply to Dão Gottwald [:dao] from comment #27)
My understand is that all the things you noted are the expected behavior after bug 1835890 which landed after this one.
I'm getting different results than the expected behavior described in Comment 18:
- Expected result: When the menu is opened, the keyboard focus is placed to the topmost menu item (Bookmarks) and the then navigate with arrow keys or tab/shift+tab
Actual result:
- no item is focused inside the sidebar switcher menu
- tab/shift+tab will collapse the sidebar switcher menu
- Expected result: Press enter or space to select a focused sidebar
Actual result: Pressing space doesn't select the focused sidebar
Comment 29•1 year ago
|
||
(In reply to Ina Popescu, Desktop QA from comment #28)
(In reply to Dão Gottwald [:dao] from comment #27)
My understand is that all the things you noted are the expected behavior after bug 1835890 which landed after this one.
I'm getting different results than the expected behavior described in Comment 18:
- Expected result: When the menu is opened, the keyboard focus is placed to the topmost menu item (Bookmarks) and the then navigate with arrow keys or tab/shift+tab
Actual result:
- no item is focused inside the sidebar switcher menu
- tab/shift+tab will collapse the sidebar switcher menu
- Expected result: Press enter or space to select a focused sidebar
Actual result: Pressing space doesn't select the focused sidebar
Yes, what I'm saying is that the actual result is the expected behavior after bug 1835890. Comment 18 predates bug 1835890.
Comment 30•1 year ago
|
||
Thank you for clarifying this.
Marking as VERIFIED FIXED.
Description
•