Great idea. I have always since Windows 95 used shift-f10 for bringing up context menus. I think many other people may have learned this as well. It's just habit at this point. F10 for showing/bringing up the menu is also a great idea. As you pointed out it is used in many places for that already. I am just learning that now, always used alt myself.
So a big +1 from me. BR, Jeremy On Wed, Sep 6, 2023 at 3:28 AM Felix Ernst <felixer...@zohomail.eu> wrote: > 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 >
