[Kde-accessibility] KDE Accessibility - sorry, off topic.

[Olaf Jan Schmidt]

[ Bill Haneman ]
> Actually in the Windows world all of those are frequent use cases for
> screen readers.  In conjunction with magnification or onscreen
> highlighting, screen readers can be especially useful for partially
> sighted users and users with reading/cognitive difficulties.

Yes, I am aware of this.

I should have written: "The existing screen magnifiers on Windows fail to 
address the needs of the majority of partially sighted users. The existing 
screen magnifiers on Unix fail to address the needs of about 95% of partially 
sighted users (both according to my non-representative experience)."

> The "partially sighted" use case is the reason why both gnopernicus and orca
> have integrated magnification and screen reading into one system.

The usability test we conducted with partially sighted users shows that no two 
partially sighted users are the same. Most of them do not want to use screen 
magnifiers for various reasons.

For example, Gnopernicus does not offer all of the false colour modes 
available with Windows screen magnifiers, which is especially problematic 
since all of the predefined colour schemes in GNOME invert the colours for 
selected text. This makes the text unreadable for the majority of partially 
sighted users.

I know partially sighted people who are using KDE with a user-defined colour 
scheme, very big font settings and different virtual screen resolutions. The 
problem with this is that focus tracking and highlighting is currently not 
available independent of screen magnifiers and screen readers. Another 
problem is that not all applications follow the user-chosen colours, which we 
hope to address in KDE4. These users would benefit from speech feedback, 
focus highlighting, etc, even if a full-featured screen reader is the wrong 
solution for them.

> I would like to discuss the German company's concerns, since I do not
> see gnopernicus, orca, or gok as "special purpose".  By their nature and
> design they are intended to be used for a wide variety of end-user
> needs.

We only touched on-screen keyboards very briefly. We were mainly talking about 
how they use existing KDE technologies, such as kttsd, and how small, modular 
accessibility aids serve them best.

But let me summarise what I learned from other people who told me that a 
simply on-screen keyboard is missing in KDE:

Can you configure GOK not to interfere with the core pointer, but to respond 
to it? Can you do so using the graphical configuration dialog alone? Why is 
this not the default setting?

Is it possible to show different (or no) buttons depending on the active 
window? Can you configure this graphically?

If you have only one mouse connected to your computer and start GOK in default 
mode, is it then possible to access the configuration dialog with your mouse? 
My experience is that this is typically completely broken on the demo points 
of GNOME during trade fairs, but maybe this was a bug in the distributions 
they use.

> Now that the XEvie extension is widely available, I think there is a
> solution available which GOK can be modified to use, but SOK will run into
> these problems too unless they adopy a different design strategy.

I agree that SOK will not solve the use cases where core pointer emulation is 
needed, but in cases where core pointer emulation is unwanted, it will 
hopefully be a good alternative.

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/