Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)

[Peter Korn <Peter Korn Sun COM>]

Hi Francesco,

Please see my answers/responses in-line, below.

> ...
> I have added the "Improve efficiency of the GNOME desktop for 
> mouse-only users" to the above mentioned wiki page. In fact, GNOME is 
> lacking (or did I miss it?) an onscreen keyboard targeted 
> specifically at people that have no difficulty to move the 
> mouse/pointer (regardless of whether it is a standard mouse or some 
> adaptive hardware like a headpointer), but are not able to use a 
> hardware keyboard.
>   

It may be that OnBoard fits this bill reasonably well.  But I'm not 
familiar enough with the motivations behind OnBoard to say whether it is 
expressly targeting the population you describe.

> For users that have difficulties to use the mouse button, there is 
> mousetweaks that should fill the gap. Unfortunately, I have not found 
> any keyboard on linux as efficient as the commercial product that I 
> am using on the other operating system:
>
> There is dasher that is reputed to have a good prediction engine; but 
> it seems to lack the possibilities to control the desktop.
>
> There is gok, which seems to be rather targeted at users that can not 
> efficiently use the pointer. It has word completion without word 
> prediction. The keyboard is not resizable,...
>
> Should dasher be enhanced, should the composer in gok be enhanced, or 
> should a new project aimed at the mouse only users be started from 
> scratch? I don't know.
>   

I think the best place to start is for you to describe the feature(s) 
you like and use in the commercial product(s), and let that lead a 
discussion of how best to achieve those results.  The more detailed you 
can be (both in the description of the feature(s), and in describing how 
they help you and aid efficiency/productivity), the better.

> By the way, the GetInvolved page mentions porting gok to python. Why the port?
>   

GOK uses a set of C language bindings to AT-SPI.  In part as part of a 
move away from CORBA dependencies, we have introduced the pyatspi 
interface, Python bindings that can are designed in part to be layered 
on top of DBUS.  This library is being shared by a number of tools, and 
if GOK were ported to Python, it could very easily move to pyatspi (in 
fact, it would be the natural thing to use).  Also, Python being a 
higher-level language than C, numerous programming headaches go away 
(like memory management).  Finally, per-application scripting is very 
easily accomplished in Python - Orca makes great use of this.  There are 
a number of use cases in which per-application on-screen keyboard 
behavior would be very useful.

> Cheap Head Mice? The adaptive Headpointers that I know of, use 
> special reference items weird by the user to track his movement. I 
> wonder whether a simple camera (webcam) working without a reference 
> item can be accurate enough to use it as headpointer. Does anybody 
> have any experience with "reference-less" headpointing?
>
> About writing drivers for headpointers: do you have any headpointers 
> in mind? Some headpointers (usually the more expensive models) 
> present themselves as a normal mouse to the computer and consequently 
> should work with the mouse driver shipped by the operating: this has 
> the advantage of not requiring a specific driver (and maybe the 
> disadvantage of not being customizable).
>   

I believe Steve Lee already addressed this question.  Let me add that 
the Inference folks at Cambridge (who brought Dasher to the world) are 
working on the OpenGazer project (see 
http://www.inference.phy.cam.ac.uk/opengazer/), which uses a "£50 
Logitech QuickCam Pro 4000" to drive eye tracking (with somewhat limited 
resolution), which in turn can drive Dasher or some other on-screen 
keyboard.  This is work I would very much like to see expanded and refined.

> Another point I am wondering about: Am I right when I think that 
> there is a standard about making the computer accessible for users 
> that can only use the keyboard!? If it is true, maybe that a standard 
> for people that can only use the mouse (with and without buttons) 
> could also be useful.
>   

There is a very fuzzy line between what apps do for accessibility in and 
of themselves, and what they do via the use of an assistive technology 
application.  For a variety of reasons, on Windows & in GNOME & in KDE, 
we have drawn that line such that keyboard-only operation is handled by 
the apps themselves, while mouse-only is done via desktop AT.  Of 
course, "keyboard-only" is only about "full use of keyboard-only".  We 
bring in AT with things like StickyKeys, MouseKeys, etc.  On Macintosh, 
"full use of keyboard-only" requires desktop AT (VoiceOver) to give you 
all of the functionality you have in Windows & GNOME & in KDE.  Which 
goes to the point that the line is fuzzy in desktop computing.

For essentially these historical and "current state of the art" reasons, 
I think it is best to solve full use by mouse only via add-on (though 
perhaps built-in to GNOME) AT which accomplishes that task, and utilizes 
the AT-SPI standard for driving apps where needed (e.g. with the 
AccessibleSelection, AccessibleAction, AccessibleValue, etc. interfaces).


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.