STEPS TO REPRODUCE

1. Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)

EXPECTED RESULTS

1. 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
2. User can simply arrow key navigate to select different options and enter to select
3. All sidebars, including Synced Tabs, which is not XUL, support this.

ACTUAL RESULTS

1. Shift-tab does not give sidebar switcher focus, and it appears that it is not keyboard accessible in any way

Marking this a P3. I'm surprised it wasn't in the original spec.

(In reply to Ryan Feeley [:rfeeley] from comment #0)

1. 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.

2. 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?

2. User can hit enter to open menu and then navigate with arrow keys, and enter again to select an option
3. 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)?

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.

(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.

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?

(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.

Updated to remove mention on making the switcher focused by default. Perhaps will follow up in another bug (which requires further debate)

Ug. This doesn't use PanelMultiView, so we'll need yet another piece of custom key nav code to make this work as desired.

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

(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?

Testing on Windows in case that's relevant; maybe this works on some other platform(s).

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.

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.

Any chance of just updating this to use PanelMultiView? That would give you keyboard navigation "for free".

(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 :)

(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.

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

(In reply to Ryan Feeley [:rfeeley] from comment #0)

STEPS TO REPRODUCE

1. Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)

EXPECTED RESULTS

1. 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
2. User can simply arrow key navigate to select different options and enter to select
3. All sidebars, including Synced Tabs, which is not XUL, support this.

ACTUAL RESULTS

1. 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:

1. 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
2. the keyboard focus does not move to the menu, thus it is not testable if the menu items are accessible with a keyboard
3. user cannot activate the menu with Enter

The patch is under the review.

The updated STR and expected behavior is below:

STEPS TO REPRODUCE

1. Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)

EXPECTED RESULTS

1. User can shift+tab or tab to give the switcher target focus.
   1.1. Screen Reader would announce that the button is in collapsed state and that the menu/dialog is opened (depending on a screen reader)
2. hit enter or space to open menu, Screen Reader would announce the update to the switcher button state - expanded
   2.1. Pressing Escape would dismiss the sidebar switcher menu, collapse the switcher target button and return the keyboard focus to the currently opened sidebar
3. 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
4. Press enter or space to select a focused sidebar
5. 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 is collapsed

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

https://hg.mozilla.org/mozilla-central/rev/e1f7aad42770

:ayeddi do you want to nominate this for 116 release notes?

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

Added to nightly and beta notes for fx116 https://www.mozilla.org/en-US/firefox/116.0beta/releasenotes/

(In reply to Anna Yeddi [:ayeddi] from comment #18)

The updated STR and expected behavior is below:

STEPS TO REPRODUCE

1. Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)

EXPECTED RESULTS

1. User can shift+tab or tab to give the switcher target focus.
   1.1. Screen Reader would announce that the button is in collapsed state and that the menu/dialog is opened (depending on a screen reader)
2. hit enter or space to open menu, Screen Reader would announce the update to the switcher button state - expanded
   2.1. Pressing Escape would dismiss the sidebar switcher menu, collapse the switcher target button and return the keyboard focus to the currently opened sidebar
3. 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
4. Press enter or space to select a focused sidebar
5. 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 is collapsed

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.

3. I've noticed that the keyboard focus is not placed on topmost menu item (Bookmarks) and the user can not navigate using tab/shift+tab inside the menu:

• no item is focused inside the sidebar switcher menu
• tab/shift+tab will collapse the sidebar switcher menu

4. Also pressing space doesn't select the focused sidebar

Should I reopen this bug or file a new one? Thanks.

(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

1. Open the bookmarks sidebar with ⌘B (Mac) or ctrl-B (Windows)

EXPECTED RESULTS

1. User can shift+tab or tab to give the switcher target focus.
   1.1. Screen Reader would announce that the button is in collapsed state and that the menu/dialog is opened (depending on a screen reader)
2. hit enter or space to open menu, Screen Reader would announce the update to the switcher button state - expanded
   2.1. Pressing Escape would dismiss the sidebar switcher menu, collapse the switcher target button and return the keyboard focus to the currently opened sidebar
3. 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
4. Press enter or space to select a focused sidebar
5. 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 is collapsed

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.

3. I've noticed that the keyboard focus is not placed on topmost menu item (Bookmarks) and the user can not navigate using tab/shift+tab inside the menu:

• no item is focused inside the sidebar switcher menu
• tab/shift+tab will collapse the sidebar switcher menu

4. Also pressing space doesn't select the focused sidebar

Should 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.

(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:

3. 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

4. Expected result: Press enter or space to select a focused sidebar

Actual result: Pressing space doesn't select the focused sidebar

(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:

3. 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

4. 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.

Thank you for clarifying this.
Marking as VERIFIED FIXED.