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

(This is a cross-post from a mail to the [email protected] 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 b=
ecause it is relevant.)

Hi!

While testing the accessibility of Dolphin for visually-impaired people I n=
oticed 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 po=
int 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 c=
ourse this doesn't work if there is no File menu in the menu bar. It also d=
oesn'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 p=
rovides.

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 outsi=
de 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 m=
enu 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.ht=
ml) workflow (quickly pressing Alt to see if a button has underlined text a=
nd 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 a=
t the bottom of the keyboard.

[1] I propose that we reserve the F10 key in most/all applications to eithe=
r 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 ke=
yboard. This functionality is provided by the "Menu" key on some keyboards.=
 However, many keyboards =E2=80=93 especially in notebooks =E2=80=93 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 origin=
ating from outside KDE is important here. Shift+F10 seems to be the typical=
 shortcut here (Web Accessibility Initiative https://www.w3.org/WAI/ARIA/ap=
g/practices/keyboard-interface/, Firefox, Microsoft https://support.microso=
ft.com/en-gb/windows/keyboard-shortcuts-in-apps-139014e7-177b-d1f3-eb2e-729=
8b2599a34).

[2] I propose that we reserve the Shift+F10 key combination to open the con=
text menu for the item that has keyboard focus. It should have the same eff=
ect 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 thes=
e 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 challenge=
d. But I assume that talking about possible ways to implement this might he=
lp 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 c=
onsidered the main menu especially in applications that do not have a stand=
ard 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 op=
en the hamburger menu if the menu bar is hidden. Since this is bound to a n=
ormal 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 th=
is.

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 im=
plemented as a Plasma-wide keyboard setting. Pressing Shift+F10 would then =
always be identical to pressing the "Menu" key on a keyboard. This idea stu=
ck 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 ot=
her solution I see is implementing Shift+F10 to trigger the context menu ev=
erywhere where context menus exist. Or, as some keyboard shortcuts interpre=
tation layer that applications can enable. If you have an idea where this s=
hould be best implemented, please let me know!

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

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