Open Bug 1259818 Opened 9 years ago Updated 2 years ago

No keyboard shortcut for Firefox Menu (AKA as hamburger menu)

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Version:
45 Branch
Type:
defect

Tracking

()

People

(Reporter: jeroenpraat, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160304114936 Steps to reproduce: Opening the Firefox Menu (AKA the hamburger menu) on the right side of the browser window with a keyboard shortcut. Actual results: I couldn't find a keyboard shortcut for this button. Expected results: Please add a keyboard shortcut for this important button. It would also be handy to use the arrow keys to select a tile when the menu is opened.
Component: Untriaged → Keyboard Navigation
Sorry, again I didn't saw this other bug.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Please don't call this the hamburger menu, it is obviously the "Cheeseburger in Paradise Menu!"
I'm not sure this is a dupe. That was for the Firefox button. This is for the hamburger menu. And, while it's been a while, I thought Australis was supposed to include a keyboard shortcut for that menu. The logic in that old bug doesn't work now, since there are plenty of functions in the hamburger menu that are not on the menu bar. Addons no longer add options to the menu bar. It actually seems like there is a huge accessibility problem, without any way to access addon features unless the addon happens to include a keyboard shortcut of its own.
I agree this is not a dupe and the other bug should just be closed because the button it referred to no longer exists. Pleas do no re-dupe this without a very good explanation.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
OK, my bad. Thanks for reopening this.
It appears fixing this will not be as quick as I had expected, since similar functionality is handled in c++ classes and so it requires becoming familiar with a lot more of the core code than I thought. But, I set up a local copy of Firefox to work on this, so I think I'll keep reading the code to get enough background. In any case, it's not clear exactly what should happen from a user perspective. What about this as a solution for Windows? (Once agreed for Windows, I'll check out other platforms and suggest the parallel solutions.) If you press Alt, not only does the menubar appear at the top of the browser as it does now, but also the toolbar (where the hamburger menu and the Web extensions are) gets overlay icons: running right to left these could be M, 1, 2, 3, 4, 5, 6, 7, 8. Alt + M opens the menu. Alt + 1 opens the first Web extension (or other button) to the left of the Menu, and so on. Alt+9, copying how tabs work, opens the Web extension on the far left. Once the menubar (where the hamburger menu and the Web extensions are) is in focus, left / right arrows work in the menubar just as they do in the toolbar (where the file menu is at the top of the browser) to move between buttons.
Flags: needinfo?(mzehe)
Yes, there is a much bigger problem here, since those menu panels are not accessible, never have been. That's why, on Windows when you press the Alt key, the "old" Windows XP-style menu bar is still there and carried forward. I know Gijs was working on this years and years back, but it was dropped due to the markup being too non-standard to easily make accessible. I don't know if this has changed, I must admit I've largely ignored this thing for years, since it was never relevant to visually impaired users, for example, since they had the old menu to work with. If this is going to change, adding a keyboard shortcut alone is not enough to make this accessible. I don't know what magic it does, but right now it is largely oblivious to accessibility, firing no focus events, keyboard shortcuts not reacting once the menu is open (like left or right arrows etc.), etc., etc.
Flags: needinfo?(mzehe) → needinfo?(gijskruitbosch+bugs)
We added a shortcut in bug 881937. All the code was backed out in bug 946395. You can read about the reasons and challenges in those bugs. Basically, the point is we have no control over what is in that menu. It's nice to say that arrows should switch between buttons - what about the search bar (how would you arrow through the bar itself?), or other more complex UI added by add-ons? It's just a complex subject, and it would be very hard to get to a point where the a11y story was both coherent, consistent AND predictable/intuitive/discoverable. It should be tackled if/when we get rid of the main menu bar. I don't think anybody is planning to do that any time soon, and so I don't think this is a priority right now.
Flags: needinfo?(gijskruitbosch+bugs)
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=881937
The reason it interests me is that I created an accessibility Web extension, and there's no way to get it to with the keyboard. It uses very standard extension code for Web extensions, which the documentation says will be the standard going forward for Firefox extensions: a browser action, with a default_popup. Would it make more sense, then, to add a Web extensions submenu to the Tools menu in the main menu bar? I could use a different type of extension to fix this for just my extension, but would something that fixes it for all Web extensions with popups be preferred?
actually, that should be all Web extensions with browser actions, whether or not there's a popup
(In reply to Suzanne Taylor from comment #9) > The reason it interests me is that I created an accessibility Web extension, > and there's no way to get it to with the keyboard. It uses very standard > extension code for Web extensions, which the documentation says will be the > standard going forward for Firefox extensions: a browser action, with a > default_popup. Would it make more sense, then, to add a Web extensions > submenu to the Tools menu in the main menu bar? I could use a different type > of extension to fix this for just my extension, but would something that > fixes it for all Web extensions with popups be preferred? I don't know, this is a question for the web extensions folks. The keyboard accessibility of the web extensions browser actions shouldn't depend on the main menu's accessibility though, at least not for the default placement in the toolbar... Anyway, the webextensions side of this probably warrants another bug, but I'll ping folks just to get their attention anyway. Kris, have the webextensions team thought about this? Seems like in Chrome, it's possible to use 'tab' to navigate the toolbar and (I assume, haven't checked) activate extension-provided panels / browser actions.
Flags: needinfo?(kmaglione+bmo)
The browser action keyboard shortcut issue is bug 1246034. That only applies to extensions which explicitly provide a keyboard shortcut, though.
Flags: needinfo?(kmaglione+bmo)
(In reply to Kris Maglione [:kmag] from comment #12) > The browser action keyboard shortcut issue is bug 1246034. That only applies > to extensions which explicitly provide a keyboard shortcut, though. Right... do we have plans to make any of the others accessible? If not, who could drive those plans from within the webextensions group? It shouldn't be the case that only mouse users can use these items.
Flags: needinfo?(kmaglione+bmo)
No plans at the moment, no. I suppose we could add entries for them to the tools menu, but it seems like it might make more sense to just make all toolbar/menu buttons keyboard accessible.
Flags: needinfo?(kmaglione+bmo)
1325692 - [commands] Explicit support for overriding built-in keyboard shortcuts by WebExtensions <https://bugzilla.mozilla.org/show_bug.cgi?id=1325692>
Blocks: 1418973
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #14) > No plans at the moment, no. I suppose we could add entries for them to the > tools menu, but it seems like it might make more sense to just make all > toolbar/menu buttons keyboard accessible. Depends. I know you can't please everyone but my mouse pointer often rests around where the middle of the hamburger menu opens up to. So instead of memorizing shortcuts for all the things I use I'd rather hit a keyboard shortcut to open the menu and continue from there. But I recognize that it's a fringe case.
Severity: normal → S3

Clarify summary. For keyboard-dependent users, the entire Firefox App Menu is not keyboard accessible because the button isn't.

Summary: No keyboard shortcut for Firefox Menu (AKA as hamburger menu) → Firefox App Menu button (aka hamburger menu) is not keyboard accessible, no shortcut

(In reply to Thomas D. (:thomas8) from comment #18)

Clarify summary. For keyboard-dependent users, the entire Firefox App Menu is not keyboard accessible because the button isn't.

This isn't really true? You can reach the button with the keyboard and can then access the popup with the keyboard. For example, ctrl-L (or cmd-L on macOS) reaches the url bar, after which you can [tab] to get to the button group at the end of the toolbar, and then arrow key to the hamburger button. Space/enter (depending on the OS) activates the button.

I'm reverting the summary.

Summary: Firefox App Menu button (aka hamburger menu) is not keyboard accessible, no shortcut → No keyboard shortcut for Firefox Menu (AKA as hamburger menu)

While technically true, I'd say that it's not intuitive that an app button would be accessed that way. Perhaps a compromise to say that the menu is not easily (or quickly) keyboard accessible?

(In reply to :Gijs (he/him) from comment #19)

… the url bar, after which you can [tab] to get to the button group at the end of the toolbar, and then arrow key to the hamburger button. Space/enter (depending on the OS) activates the button. …

True, however I would never have imagined so convoluted an arrangement for the main menu of an application.

… the url bar, after which you can [tab] to get to the button group at the end of the toolbar, …

For clarity, the number of keystrokes (with Firefox on FreeBSD):

  1. Control-L to the location field
  2. Tab to the first button of the group within the location field
  3. Tab beyond the location field, to the first button of the next group
  4. Right
  5. Space

– at least five steps, instead of one shortcut.

I'm relatively lucky, in that only eight steps are required, because I keep as few buttons as possible in the second group.

Other users might prefer visibility of buttons. A person with a dozen extensions might require fifteen steps to reach the main menu …

(In reply to Graham Perrin from comment #21)

… only eight steps are required, because I keep as few buttons as possible in the second group. …

Correction, sorry: what was pictured (linked) above was the result of keying Space for the overflow menu. I prefer the main menu to the left, far left; it's nine steps in my case.

The severity field for this bug is relatively low, S3. However, the bug has 11 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dao+bmo)

I consider this still relevant. I'd also add that it's parity Chrome, as Chrome will automatically select its menu if you press ALT or F10. You then press down to open the menu, or can move it over to other buttons.

When adding shortcut, please keep compatibility with classic menu for users. Keys F10 and Alt are still being used for access to the original / classic / old menu (File, Edit, View, History, Bookmarks, Tools, Help; as a line at left top corner),
so it is neccessary to test new feature when old menu is switched on.

I suggest to make possibility to move cursor between that two menus e.g. by left/right arrow key.

You need to log in before you can comment on or make changes to this bug.