[Kde-accessibility] making fallback access keys configurable

Bill Haneman Bill.Haneman at Sun.COM
Fri Mar 3 11:43:19 CET 2006

Hi Olaf/All:

Having worked on keyboard navigation issues for Gnome, mozilla, etc. for
the past 5 years, I agree with your points, except for the suggestion
about F8.  Using function keys as modifiers is a very bad idea, and poor
from an accessibility standpoint.  A 'standard' modifier should be used,
consistent with the rest of the desktop.  I would suggest 'Alt' except
for the fact that it would clash with menu keynav.  "Control" seems like
the best of the available solutions, even if it is not ideal.


On Fri, 2006-03-03 at 10:16, Olaf Jan Schmidt wrote:
> Hi!
> We are currently repeating a discussion we had on the kde-hci list close 
> before the release of KDE 3.5.
> I will summarise the outcome:
> * The accesskey feature itself cannot be removed or turned into a hidden 
> configuration option without breaking the string freeze (the "HTML 4.01 
> built-in" would have to be changed to "HTML 4.01 partially supported").
> * The fallback keys are a very nice accessibility feature, even if the 
> accessibility team did not request it. When we discussed this last, I 
> consented to removing it before the 3.5 release if the usability team 
> suggests so. They did not have a consensus on it. I don't think it is a good 
> idea to silently remove or hide it now in a minor release after users have 
> got used to it.
> * Requiring the user to press the Ctrl key twice, or to hold down the key for 
> a longer time, would clash with the accessibility keyboard settings. This is 
> especially true if combined with a timeout. Remember that severely impaired 
> users are among those who use accesskeys, and they are typically much slower 
> in handling the keyboard.
> * To avoid usability problems, it would be best to replace Ctrl with some 
> other shortcut, e.g. F8. It is easy to make this change for KDE4, when we 
> will address the keyboard navigation in KDE altogether.
> * Changing the shortcut within in a minor release or a dot release only makes 
> sense if we find a way to make accesskey users aware of the change. The 
> usability team found no solution for this when we discussed it last time.
> * It seems that the resistance to the accesskeys partly comes from some bugs 
> in the implementation that I personally have difficulties reproducing. I also 
> don't want to take maintainership for every accessibility-related feature or 
> bug in KDE. I am already short of time writing proper accessibility 
> guidelines for developers, which makes more sense long-term than trying to 
> fix accessibility problems myself while other developers open new ones all 
> the time.
> Olaf
> -- 
> Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
> accessibility networker, Protestant theology student and webmaster of 
> http://accessibility.kde.org/ and http://www.amen-online.de/
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility

More information about the kde-accessibility mailing list