[Accessibility] Re: [Accessibility-kbd] KDE's implementation of the Keyboard Access Functional Specification, RC1

Bill Haneman Bill.Haneman at Sun.COM
Wed Mar 15 07:26:30 PST 2006


On Wed, 2006-03-15 at 13:21, Gunnar Schmi Dt wrote:
> Hello,
> 
> I just recognized that my mail may sound as if the most important point is 
> that KDE does not fullfill the requirements of the specification. In fact 
> the limitations that arise from the failure to implement the specification 
> are only very minor ons as I will explain below.
> 
> In any case I wrote the mail because I wanted to discuss about the points 
> where KDE differs from the specification.
> 
> On Wednesday 15 March 2006 13:04, Gunnar Schmi Dt wrote:
> > [...]
> > In particular KDE's implementation differs in four points from the
> > specification:
> 
> The fact that KDE differs from the specification does not need to imply 
> that KDE violates the specification in all of the four points. In at least 
> one of the points it is more of a broad interpretation.
> 
> > a) I addition to the time-out option the specification requests that
> > there is a never-time-out option for StickyKeys and SlowKeys. KDE 3.5
> > does implement the time-out option, but not the never-time-out option
> > (it will always turn off both StickyKeys and SlowKeys if the timeout
> > occurs).
> 
> In order to make clear what is meant here I will rephrase the statement in 
> other words: KDE allows you to enable a timeout for both StickyKeys and 
> SlowKeys. If the timeout occurs, both features are turned off, but if you 
> do not need the timeout, you can turn it off. What is not possible is to 
> use the timeout e.g. for StickyKeys only and to leave SlowKeys turned on.

Right - if the proposed spec requires independent timeouts, we should
revise the spec, as that is not technically implementable (at least
cleanly) via XKB.

> 
> We might wonder, though, whether we really need the never-time-out option 
> for StickyKeys and SlowKeys individually or whether it is enough to 
> provide the possibility to turn off the timeout.

A timeout for both is the usual solution and I think it's quite
adequate.

> > b) The specification requests that it is possible to request an audible
> > signal when SlowKeys is about to be turned on/off via the keyboard. The
> > only way to do that with KDE 3.5 is to globally activate an audible
> > signal when any keyboard accessibility feature is turned on or off from
> > the keyboard (which by itself is an other request from the
> > specification).
> 
> How common is it to turn on either signal but to turn off the other one? I 
> guess that it is not very common to turn on the warning for when SlowKeys 
> is about to be turned on or off, but to turn off the information for when 
> the keyboard behavior did actually change. The other way round (turning 
> off the warning, but to turn on the information) sounds to be more 
> reasonable, though.

XKB provides for audible notifications when SlowKeys is about to be
turned on or off.  This is a different audible signal from the one used
when StickyKeys is being turned on.

> > c) KDE 3.5 provides the user with the possibility to specify the repeat
> > interval of the MouseKeys. The specification talks about an initial
> > pointer velocity, which can be translated into a repeat interval if you
> > know the initial pointer step size. When extending KDE's keyboard
> > accessibility settings I chose to offer a repeat interval instead of an
> > initial velocity because I feel that the effect of the setting is better
> > described by the repeat interval (the current X.Org implementation seems
> > to always use the same repeat interval while increasing the size of the
> > jumps).
> > [...]
> 
> I want to add that you need to translate the initial velocity into a repeat 
> interval when you want to implement settings requested by the 
> specification. If the specification is to be a technical specification I 
> would suggest to modify the specification to follows KDE's behavior (which 
> is the same as the settings offered by X).
> 
> > d) The specification requests that the minimum value of the delay between 
> > the initial step and the acceleration of the Mouse Keys is 0, whereas KDE 
> > 3.5 uses 1 ms. When looking at the behavior of the MouseKeys, I wonder if 
> > both minimum values are too small. A delay of 0 ms would mean that the 
> > initial step and the first step of the acceleration are done at the same 
> > time, so that the user only recognizes one larger step.
> 
> In order to make it clear: I suggest to increase the minimum value for the 
> delay between the initial step and the acceleration to a value >= 1ms.
> 
> Gunnar Schmi Dt
> -- 
> Member of KDE's Technical Working Group
> Co-maintainer of the KDE Accessibility Project
> Maintainer of the kdeaccessibility package
> http://accessibility.kde.org/
> 
> ______________________________________________________________________
> _______________________________________________
> Accessibility mailing list
> Accessibility at lists.freestandards.org
> http://lists.freestandards.org/cgi-bin/mailman/listinfo/accessibility




More information about the Accessibility mailing list