Let's reserve F10 and Shift+F10 for accessibility

[Jeremy Whiting]

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 <felixernst at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20230906/d947381a/attachment.htm>