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

[Bill Haneman <Bill Haneman Sun COM>]

On Wed, 2006-08-16 at 20:44, Olaf Jan Schmidt wrote:
> [ 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)."

That strikes me as a surprising statement.  Of course it depends on what
you mean by
"partially sighted".

> > 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 really wonder where you got this data, it is at odds with the
information I have received from domain experts.

It would not be difficult to add more false color modes to gnome-mag and
by extension any gnome-mag client such as orca.  However I don't think
this is by any means our most pressing magnification need.

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

Doing this requires some sort of re-rendering or overlay feature.  Until
the recent introduction of XComposite this sort of thing was technically
not very feasible on XWindows.  Fortunately we have multiple ways of
doing it now.  But I still think that it may make sense to implement it
as an orca add-on.

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

Theming is a very important issue and as you no doubt realize, it can be
difficult to get applications to comply with themes, it seems that most
applications want to define their own color schemes for at least some
things.

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

In general this is technically impossible for ANY onscreen keyboard in
XWindows - at least, without XEvie.  I think that we may be moving GOK
to this sort of default setting now that properly-working versions of
XEvie are more widely available.

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

Yes, this can be done.  But eventually an orca-like python scripting
approach may make the most sense for this sort of application-dependent
behavior.

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

Yes.

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

That could be.  The default configuration is pretty bad for GOK, and for
technical reasons the necessary solution is to hand-edit the X
configuration files.  We have documented this process in the 'Gnome
Accessibility Guide' but it's not pretty!

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

I think you misunderstand.  SOK will have problems for the very reason
that it uses the core pointer as its activation input device.  This
leads to "lockout" scenarios and strange behavior because of
applications and toolkits assert "ownership" over the pointer device in
various ways.

Bill

> 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 kde org
> https://mail.kde.org/mailman/listinfo/kde-accessibility