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

[Gunnar Schmi Dt]

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.

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.

> 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.

> 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/accessibility/attachments/20060315/809639fa/attachment.pgp