All access keys for UI elements in Options and Account Settings tabs are not working, and some conflicting with main menu. Looks like fallout from changing these from dialog windows to tabs. That's BAD for keyboard accessibility, imo qualifies for severity S2. But at least pressing tab a thousand times to reach the intended UI element which you want to change stilll works.

Affected:

• TB 68 for Options tab (Account Settings still in a dialogue and working correctly)
• TB 78 and Daily for both Options and Account settings tabs. Account settings is TB78found.

STR (by example)

• On Windows, open Options tab (by analogy for Account Settings tab).
• Press Alt+W (content access key for _W_hen Thunderbird launches, show the start page...).
• Press Alt+M (content access key for When Daily is _m_inimized, move it to tray)

Actual result

• Alt+W (any content access key not used in main menu): nothing
• Alt+M (any content access key also used in main menu): triggers Message menu (main menu access keys override content access keys)

Expected result

• Content access keys for UI elements are important for accessibility and efficiency and they should work!
• There should be no conflicts between main menu and content access keys.

This is a fallout from flattening those contents into tabs. Strange that this was not considered nor noticed at the time...

Considerations for fixing this

• Access keys are required for accessibility and ux-efficiency, so we must make the content area respond to Alt+* key combinations again.
• Having it both ways will be hard (albeit possible): main menu eats up 8 access keys which may conflict with content access keys.
• Main menu isn't doing anything useful for Options/Account Settings: virtually all main menu options are disabled.
• I think we should allow main menu access for Options/Account Settings tabs only with pressing Alt first, then the main menu access key (already works, but must be made exclusive here). That will allow us to consume any actual Alt+* keypresses (where you hold down Alt while pressing another key) for the content. Alternatively, all locales would have to recheck all content access keys here and eliminate conflicts with main menu.

Note that accessibility is crucial for Thunderbird deployment in public authorities and enterprise.

For in-content pages you need the SHIFT together with the normal access keys (SHIFT+ALT+W in prefs/General for the start page checkmark).

Key combinations that are used for radio button's don't work. For instance, you can't move to the "_C_onfig Editor…" by pressing Alt+Shift+C, because focus won't move from/past "_C_heck for Updates" to the radio button "_C_heck for updates, but let me choose whether to install them" under "Allow Daily to".
I've filed core bug 1660234 for that.

(In reply to Richard Marti (:Paenglab) from comment #2)

For in-content pages you need the SHIFT together with the normal access keys (SHIFT+ALT+W in prefs/General for the start page checkmark).

any alternatives?

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

(In reply to Richard Marti (:Paenglab) from comment #2)

For in-content pages you need the SHIFT together with the normal access keys (SHIFT+ALT+W in prefs/General for the start page checkmark).

any alternatives?

According to this page, the modifiers depend on the browser (including Thunderbird) and operating system:

https://en.wikipedia.org/wiki/Access_key

There's also a preference to change the modifier: ui.key.contentAccess

http://kb.mozillazine.org/Ui.key.contentAccess

When I filed the bug, I was honestly thinking that access keys are completely broken - we've had native Alt+* access keys (Windows/Linux) for the entire application ever since the inception of Thunderbird. I now understand that "inline" content requires the web-style access keys (Alt+Shift+* by default). Unfortunately, that's undiscoverable, undocumented, partly broken, and inconsistent throughout our application.

We have several problems here:

• ux-implementation-level: The user knows nothing about our internal change from native XUL ( Alt+* ) to inline XHTML ( Alt+Shift+* ) and the consequences thereof.

  User experience principle: interfaces should not be organized around the underlying implementation and technology in ways that are illogical, or require the user to have access to additional information that is not found in the interface itself.

• ux-consistency: In some content areas of our application, native Alt+* access keys are still working (and I am not talking about menus where they must always work for consistency with the platform): Alt+R = From, Alt+S = Subject, Alt+A = Add to To (contacts side bar), Alt+I for View button (from 3-pane toolbar customization palette), and so on... So it now becomes a guessing game.
• More consistency surprises: Strangely, even the main menus react to the in-content access keys Alt+Shift+* (Alt+Shift+F for File menu works in Thunderbird, Firefox, but even in Windows Explorer and Notepad) - I'm not sure but I guess that's an oversight in the code (not checking for absence of Shift key), because official MS documentation still mentions Alt+* [1] for the traditional access keys. At least, in-content Alt+Shift+* takes precedence over the menu access keys (Account Settings Alt+Shift+N will focus Account Name text input, not open the Event menu, which is Alt+N).
• Buggy from platform: e.g. bug 1660234 - Alt+Shift+* fails for radio options.
• ux-discovery: No way for users to find their way in this mess from in-product hints or documentation.
• Undocumented: I guess there's zero documentation on these issues.

[1] https://docs.microsoft.com/en-us/windows/uwp/design/input/access-keys

I 100% agree with the assessment of Thomas.

ux-discovery: No way for users to find their way in this mess from in-product hints or documentation.

This concerns me a lot.
There a lot of things that should happen in order to improve the overall discoverability and accessibility of Thunderbird, but before doing anything, we should define a coherent plan of action that can help us define a single source of truth for the entire application.

So far, we've been defining access keys and shorctuts inside xhtml files and fluent files, based on what was needed in a specific location.
Nothing is centralized, and if a shortcut is not defined on a menu item, the discoverability is basically an impossible guessing game.

We should spend some time in defining a plan of action and come up with a centralized and scalable solution.

I'm not sure if Thunderbird should handle this different than Firefox does, although Firefox has much less xhtml-UI that uses this modifier, but for those areas in Firefox that do use it, it is equally undiscoverable and undocumented...

Anyway, by setting ui.key.contentAccess equal to ui.key.chromeAccess (e.g. 4) you can restore the normal (Alt or Option) access key modifier for xhtml. Except maybe for bug 1660234...

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #8)

Anyway, by setting ui.key.contentAccess equal to ui.key.chromeAccess (e.g. 4) you can restore the normal (Alt or Option) access key modifier for xhtml. Except maybe for bug 1660234...

And except for all the extra conflicting access keys because of all the menus that are accessed also by Alt...