Bug 1661679 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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

Back to Bug 1661679 Comment 6