Let's reserve F10 and Shift+F10 for accessibility (cross-post)

[Felix Ernst]

(This is a cross-post from a mail to the kde-devel at kde.org mailing list. I consider the other one to be the main mailing list of discussion, so try to answer there if you want everyone to read it. I only also send this here because it is relevant.)

Hi!

While testing the accessibility of Dolphin for visually-impaired people I noticed that the menu bar is not part of the normal Tab key focus chain. The same seems to be true for all KDE applications I tested. I brought this point up with KDE's accessibility group (#kde-accessibility:kde.org) and was told that that is normal. Instead, users are supposed to be able to open a menu using either the Alt key or the F10 key.

Unfortunately, KDE software doesn't seem to follow that rule either, so the only way to focus the menu bar using only a keyboard would be to hold down the Alt key, notice the accelerators in the menu bar (i.e. an underlined F in File), and then press for example Alt+F to open the File menu. Now of course this doesn't work if there is no File menu in the menu bar. It also doesn't work if the application uses a hamburger menu instead of a menu bar. A blind user won't be able to identify which kind of menu an application provides.

We need a consistent way for visually-impaired users to open a menu or some users won't be able to use every action our applications offer! The way to open a menu should also be consistent with software originating from outside of KDE, so a user can open a menu without having to know if it is a KDE application or not.

>From what I can tell, F10 is the only sensible choice here. F10 to open a menu is what many design guidelines seem to already follow:
- Gnome https://developer.gnome.org/hig/reference/keyboard.html
- Microsoft https://support.microsoft.com/en-gb/windows/keyboard-shortcuts-in-apps-139014e7-177b-d1f3-eb2e-7298b2599a34
- Chrome
- Firefox (but Alt also works here)
- (Web Accessibility Initiative mentions Shift+F10 but not F10 https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/)

The only other key that even made sense to consider to me was the Alt key, but this doesn't seem like a good idea IMO, because:
- it conflicts with the accelerator (https://doc.qt.io/qt-5/accelerators.html) workflow (quickly pressing Alt to see if a button has underlined text and can be directly activated)
- it might lead to accidental activation especially in the context of using keyboard shortcuts that also use Alt, but also purely because the key is at the bottom of the keyboard.

[1] I propose that we reserve the F10 key in most/all applications to either open the first menu in the menu bar or open the hamburger menu (depending on application).



A completely separate issue is the opening of context menus using only a keyboard. This functionality is provided by the "Menu" key on some keyboards. However, many keyboards – especially in notebooks – do not have a menu key. So, we still need to provide a way to open a context menu for those. For the same reasons as above, consistency with software originating from outside KDE is important here. Shift+F10 seems to be the typical shortcut here (Web Accessibility Initiative https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/, Firefox, Microsoft https://support.microsoft.com/en-gb/windows/keyboard-shortcuts-in-apps-139014e7-177b-d1f3-eb2e-7298b2599a34).

[2] I propose that we reserve the Shift+F10 key combination to open the context menu for the item that has keyboard focus. It should have the same effect as the "Menu" key many keyboards have.



Please let me know if you agree that these are good ideas or not. Or let me know if you think I should start a discussion about this outside a mailing list. I currently can't even imagine any good alternative solution to these problems, so directly announcing that this is a change I want to work on on this mailing list makes the most sense to me for now. Any objections?


*Implementation*
This is sort of secondary to the main content of this eMail above, so feel free to ignore this section for now if my proposals above will be challenged. But I assume that talking about possible ways to implement this might help making the above ideas more clear/concrete.

I think proposal [1] (F10 opens menu) will sometimes need to be implemented in application code. It might not be clear from outside code what can be considered the main menu especially in applications that do not have a standard menu bar.
I currently plan to implement this for all users of KHamburgerMenu at once. Pressing F10 would focus/open the menu bar if it is visible or it would open the hamburger menu if the menu bar is hidden. Since this is bound to a normal action, both application code and users can re-bind F10. At the worst, this would lead to a non-crashing collision of the F10 key usage in some applications. Now, with the jump to KF6, it seems like a good time to do this.

About Shift+F10 I am not sure yet at which layer this should be implemented. Ivan Tkachenko mentioned the idea in chat that it could potentially be implemented as a Plasma-wide keyboard setting. Pressing Shift+F10 would then always be identical to pressing the "Menu" key on a keyboard. This idea stuck with me so I want to bring it to your attention here. Is it too bold to decide about the Shift+F10 key combination like this? If it is, the only other solution I see is implementing Shift+F10 to trigger the context menu everywhere where context menus exist. Or, as some keyboard shortcuts interpretation layer that applications can enable. If you have an idea where this should be best implemented, please let me know!

If you have gotten this far: Thanks for reading! I hope this eMail will lead to great improvements to accessibility in the long term.

Have a nice day!
Felix
https://invent.kde.org/felixernst