1138131 - 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)

Status: RESOLVED WORKSFORME

(Thunderbird :: Toolbars and Tabs, defect)

Description

[nithin[:lazybug]]

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

Comment 1

[Thomas D. (:thomas8)]

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?

Comment 2

[nithin[:lazybug]]

Attachment: sceenShot.jpg

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

Comment 3

[Thomas D. (:thomas8)]

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.

Comment 4

[Thomas D. (:thomas8)]

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

Comment 5

[Wayne Mery (:wsmwk)]

(let's get this out of untriaged)

Comment 6

[Wayne Mery (:wsmwk)]

like bug 1259818
found in https://bugzilla.mozilla.org/buglist.cgi?v4=app%20menu&o5=substring&f10=keywords&f1=short_desc&o3=anywordssubstr&list_id=13096933&j8=OR&f8=OP&v3=hamburger%20appmenu&o1=nowordssubstr&j2=OR&o9=substring&v10=access&classification=Client%20Software&classification=Components&f9=longdesc&f4=short_desc&v5=panel%20menu&query_format=advanced&o10=substring&v9=accessibl&f3=short_desc&f2=OP&o4=substring&f5=short_desc&product=Core&product=Firefox&product=MailNews%20Core&product=Thunderbird&f7=CP

Comment 7

[Wayne Mery (:wsmwk)]

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

Is firefox appmenu similarly broken?

Comment 8

[Alessandro Castellani [:aleca]]

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

Comment 9

[Wayne Mery (:wsmwk)]

(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

Comment 10

[Alessandro Castellani [:aleca]]

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.

Comment 11

[Paul Morris [:pmorris]]

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.

Comment 12

[Ryan Lee Sipes]

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.