1028951 - Mail View from hambuger toolbar widget - menu not accessible from keyboard

Status: NEW

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Glenn Knickerbocker]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20140609182057

Steps to reproduce:

Trying to select a view on the View pulldown (Mail View menu item) using the Alt-I keyboard shortcut


Actual results:

Alt-I gives the selection box focus but does not activate the pulldown.  Only the All and Unread views can be reached using abbreviations A and U on the keyboard.  The up and down arrows unpredictably activate the Save View as a Folder and Customize menu entries.


Expected results:

Alt-I should activate the pulldown so that both arrow keys and menu item abbreviations can be used to select from the menu.

Comment 1

[Wayne Mery (:wsmwk)]

Behaves exactly as described

Comment 2

[:aceman]

(In reply to Glenn Knickerbocker from comment #0)
> Alt-I gives the selection box focus but does not activate the pulldown. 
> Only the All and Unread views can be reached using abbreviations A and U on
> the keyboard. 

You can also select All and Unread via the arrow keys.

> The up and down arrows unpredictably activate the Save View
> as a Folder and Customize menu entries.

This means that also these other items in the menu can be selected via the arrow keys. Why merely selecting them also activates them (their dialogs) is a different question. But this also happens in all other dropdown menus I could see in TB. Try E.g. the Folder location widget. Moving over the items using arrow keys activates each of the items/folders.

Seems to be a builtin property of the menulist widget.

Comment 3

[Jim Porter (:squib)]

As a rule, toolbar widgets should *not* be keyboard-accessible. They're strictly for mouse usage. I'm not actually sure why that toolbar widget has a keyboard accelerator in the first place...

Comment 4

[Thomas D. (:thomas8)]

Imo, the XUL implementation of <menulist> is fundamentally flawed, and violates several UX principles (as seen in this bug). It also deviates unnecessarily from good practice in other well-known and wide-spread applications like MS Office (example below).

1) Keyboard-navigating a dropdown menulist must not change the menulist's value until confirmed with ENTER and menulist is closed. Changing the value and firing oncommand event for unconfirmed, simple keyboard navigation is nonsense. It's unexpected, error-prone, hence dangerous. Unless explicitly confirmed by ENTER, we have no way of telling if the user actually wanted to execute this item's option or if he is just navigating through to reach another item on the list.
2) Current implementation has lost "Cancel" functionality for menulists. Conceptually, a menulist is nothing but a condensed miniature dialogue with an implicit listbox, OK button, and Cancel button. So the expected procedure is: Browse list (by simple keyboard navigation), and after selecting intended option, confirm with ENTER (OK), or cancel with ESC (which must restore the original value of the menulist). As implemented now, there's no difference between exiting the menulist with Enter or ESC, which is obviously nonsense.
3) It's currently possible to navigate the menulist items even when it is not open. That's useless UI and again it creates de-facto undefined states. We can't tell if user really wants to execute that option or not, until confirmed with Enter. Except for very short and trivial lists (which menulists are normally not), navigating the list blindly by cursoring up and down (to unpredictable items which user can't see because list is closed) does not make any sense as it leads to unpredictable results and slows down the workflow of selecting because you have to read every single item to check if this is the right one. Pressing cursor-down or cursor-up must always open the list for visible, intentional navigation between list items.

Here's a good industry standard example of how it SHOULD work:
I'm looking at MS Word 2010 (but I don't expect other versions to behave differently):

The font selector on the "Home" ribbon is a typical menulist/combobox example, and works perfectly as expected.
Default font is "Calibri".
Click on font selector's font name part (not the dropdown arrow) to set focus.
Alternatively, a) start typing, or b) use cursor up/down.
a) typing with list closed:
--> autocompletes matching entries without opening the list; if no match, only your typing shown
--> ENTER applies the new font
--> ESC removes what you've typed and reinstates the original value: Calibri. So simple.
b) use cursor up/down on closed list
--> list opens for visual navigation of list items
--> ENTER applies the new font
At some point, Word introduced "live preview" for font list navigation.
For state-changing things, that makes sense. Note that the new font is NOT permanently applied until you press ENTER. So Font-change-command is NOT fired until you confirm your choice with ENTER.

Comment 5

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #4)

> Alternatively, a) start typing, or b) use cursor up/down.
This should read:
*Then, either* a) start typing, or b) use cursor up/down.

> b) use cursor up/down on closed list
> --> list opens for visual navigation of list items
> --> ENTER applies the new font

--> ESC closes the list and reinstates the original value: Calibri. So simple.

Comment 6

[Thomas D. (:thomas8)]

(In reply to Jim Porter (:squib) from comment #3)
> As a rule, toolbar widgets should *not* be keyboard-accessible. They're
> strictly for mouse usage. I'm not actually sure why that toolbar widget has
> a keyboard accelerator in the first place...

I guess it's a ux-efficiency thing: "View: ..." is not just any random control, for those who need it it's an important swiss-knife thing to filter on-the-fly what they want to see. There's a vast variety of filters directly accessible via that view widget. That certainly deserves a dedicated keyboard access. The label makes sense, so offering an access key for the label is the logical conclusion. Keyboard shortcuts are hard to get, and less visible. So I think this is a high-value and hence legitimate exception.

I'm not totally sold on the traditional idea that toolbar widgets should never be keyboard accessible. If making them accessible provides ux-efficiency gains for keyboard users, why not? Mouse users will not be harmed as they just click the target directly.
Including every toolbar widget in the tab-sequence will certainly be inefficient for keyboard users.
But say, having an intelligent way of keyboard-accessing quick filter buttons might work.
E.g., we could have a *single* tab-stop on the first quick filter button. Then you can use cursor-right to shift focus to the other quick filter buttons, and use them without mouse.

Windows (10, not sure about earlier versions) have made a similar change by adding a *single* tab-stop for the column header row of their file picker tree in details view. With that single tab stop, ALL of the column headers become accessible via cursor right/left. That's a massive keyboard-efficiency gain at almost no cost.

Comment 7

[Glenn Knickerbocker]

Don't forget there are users out there with visual or manual disabilities who can't use a pointing device.  Every function should be available *somehow* through text input.  Personally, I don't care if it's through the widget or some menu entry, as long as I can find it (though I also agree that a tab stop for each menu/tool bar is generally useful).

Comment 8

[Wayne Mery (:wsmwk)]

The hamburger in the toolbar definitely is oriented to mouse users, whereas the the menu bar is better suited to users with accessibility issues. To validate that idea, consider that Firefox does lots of serious usablilty studies, and you don't see access keys in Firefox's hamburger menu. Firefox hamburger does however have a much simplifed structure compared to Thunderbird's perhaps something we need to consider and file a bug on?

Given that the menu bar is highly accessible, it is a strong, and probably the preferred alternative for serious accessibilty users.

Comment 9

[Wayne Mery (:wsmwk)]

Im not sure where this stands