Closed Bug 1138131 Opened 10 years ago Closed 5 years ago

TB's "hamburger" menu button (AppMenu) is not keyboard-accessible and keyboard focus either skips or gets stuck on dual menus (depending on the initial focus set by mouse hover)

Categories

(Thunderbird :: Toolbars and Tabs, defect)

39 Branch
x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: lazybug, Unassigned)

References

Details

(Keywords: access, Whiteboard: [dupeme])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 Steps to reproduce: click on the daily menu button in the daily-menu popup try navigating using keyboard Actual results: you cannot select the "Preferences" and "Help" menu items Expected results: you should be able to select all the menu items using keyboard
Summary: cant select menu item using keyboard → can't some select menus item using keyboard in Daily menu
On Windows 8, the hamburger menu button is not keyboard-accessible at all: you can't access the button itself via keyboard, and you cannot navigate menus with keyboard :( nithin, are you talking about the hamburger menu button? How is it accessible in Linux?
Attached image sceenShot.jpg (deleted) —
sorry for being unclear description. there is no shortcut for menu button in Linux too, i guess. i am talking about, once you open the menu on the right corner, the popup menu will be visible. hover over one of the menu item using mouse, then try navigating up and down
Yes, we are talking about the same thing. Even the same problem. It's because I started out on the Options Dual Menu (aka Preferences on Linux) that I could not move the focus at all. Only starting out on the simple popup menus works. So this is the bug: STR / -> Actual result Scenario A) starting out from dual menu: keyboard focus stuck on dual menu 1 click on hamburger TB menu button 2 hover over New Message dual menu -> message submenu opens; close it with cursor left -> now New Message dual menu is highlighted 3 press cursor down -> nothing; New Message dual menu stays highlighted, but focus is not moveable up/down by keyboard Scenario B) starting out from simple popup menu: keyboard focus skips all dual menus 1 click on hamburger TB menu button 2 hover over Save As simple popup menu -> Save As submenu opens; close it with cursor left -> now Save As simple popup menu is highlighted 3 press cursor up, trying to select New Message dual menu -> only simple menus or simple popup menus are highlighted -> dual menus like New Message are never highlighted, i.e. not keyboard accessible. Scenario C) keyboard focus also cannot be moved from the left half of the button's menu to the right half, and vice versa; focus is always stuck in the active column Scenario D) Well, the whole thing isn't keyboard-accessible anyway, because you can't even get there with keyboard only: -> no keyboard access (e.g. shortcut) to open the hamburger button Expected Result I suppose if we are taking the hamburger button serious (which may not always be true for everyone), then it should (must?) be keyboard accessible, like any other part of our app (in theory...). Alternatively, we could argue that the hamburger button is mouse-only; the keyboard alternative is using the traditional main menu, which is very accessible... There's an existing bug (probably XUL) for Scenario A) and B), assuming they have the same cause.
(In reply to Thomas D. from comment #3) > There's an existing bug (probably XUL) for Scenario A) and B) ...I think, but can't find it right now...
(let's get this out of untriaged)
Component: Untriaged → Mail Window Front End
Summary: can't some select menus item using keyboard in Daily menu → TB's "hamburger" menu button is not keyboard-accessible and keyboard focus either skips or gets stuck on dual menus (depending on the initial focus set by mouse hover)
Whiteboard: [dupeme]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: TB's "hamburger" menu button is not keyboard-accessible and keyboard focus either skips or gets stuck on dual menus (depending on the initial focus set by mouse hover) → TB's "hamburger" menu button (AppMenu) is not keyboard-accessible and keyboard focus either skips or gets stuck on dual menus (depending on the initial focus set by mouse hover)

Is this a highly desirable accessibilty issue? Or are the "normal" menus the preferred means in the accessibility community?

Is firefox appmenu similarly broken?

Component: Mail Window Front End → Toolbars and Tabs
Flags: needinfo?(alexarnaud)
Keywords: access

(In reply to Wayne Mery (:wsmwk) from comment #7)

Is this a highly desirable accessibilty issue? Or are the "mormal" menus the preferred means in the accessilibity community?

I think updating the main App Menu to behave like the the Firefox one should be a high priority for many reasons, including modernizing the user interface, improving the experience, and fixing accessibility issue.

Is firefox appmenu similarly broken?

The new one can be navigated via keyboard without problems, and it also solves the issue of accidentally moving outside the menu area, and consequentially closing it, when trying to access a submenu.

I'd be interested in trying to make a patch for it.

(In reply to Alessandro Castellani (:aleca) from comment #8)

...
I'd be interested in trying to make a patch for it.

To be resolved in Bug 1546309 ? [de-xbl] get rid of menu-vertical binding (appmenu), appmenu-vertical, splitmenu

Flags: needinfo?(alexarnaud) → needinfo?(alessandro)

Yes, the appmenu is undergoing rework in Bug 1546309.
I don't know if pmorris is adding keyboard-accessible features right away or it will come in a follow-up bug.

Flags: needinfo?(alessandro) → needinfo?(paul)

Good news: "out of the box" the new appmenu supports keyboard navigation of the menu once it's open, using arrow keys, etc. So that will be a nice improvement. Beyond that, in the current WIP state, the alt-key/accesskey shortcuts work and appear as they should, but the ctrl-key shortcuts are not currently appearing as they should, although the ones I tested still seem to function. Fixing that is on my to-do list and I'd like to include it from the start, but it's possible it could be delayed to a follow-up bug.

Flags: needinfo?(paul)

This was definitely a problem with the old menu, I experienced it too. However, this behavior does not seem to exist in my testing with the new menu. I believe this can be closed.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: