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

[Peter Korn <Peter Korn Sun COM>]

Hi Chris,
> On 17/08/06, Bill Haneman <Bill Haneman sun com> wrote:
>   
> > I think the 'simple' or 'common' cases you are thinking about are mostly
> > text entry.  For text entry you are right that the 'normal' use of the
> > pointer (plus focus rejection logic) would work, but it would not work
> > "correctly" from the user's point of view for any keyboard navigation
> > features.  These inconsistencies are always going to be viewed as bugs
> > from the user's perspective, no matter how you explain them...
> >     
>
> This is all true but we are far from a perfect solution at this point.
>  A couple of people have emailed me who use onboard/sok and say it's
> useful to them in one capacity or another and none of them have even
> noticed the menu bugs.
>
> Keyboard are primarily used as text input devices.  Almost all other
> functions can be handled by the pointer input including the menus.  If
> the menus are too small a target to hit one possible work around would
> be to increase the font size.
>
> Allowing a user 100% control over their desktop using an OSK is
> obviously the 'holy grail' that all OSK should hope eventially to
> accomplish.  It is not however necessary in most cases.

You speak to a very good point: there are mouse (or mouse-like) users 
who want to use their mouse for all GUI manipulation, and for operating 
their keyboard.  So long as the GUI targets are large enough (or the AT 
has logic to "enlarge" them in some fashion [aside: this is one of the 
few novel things I saw in a draft of Microsoft's UI Automation API]), 
this can work well.  So head-mouse and eye-gaze users would primarily be 
looking to the keyboard for text entry, and perhaps macro-type 
functionality (e.g. launch this app, inject this set of keystroke/mouse 
gestures).

I think you can get a lot further with that more constrained set of OSK 
functionality within the current X mouse-grab constraints.  Nonetheless, 
I think we'll all be better off if we can get some changes into our 
distros to better support AT tools owning the keyboard and mouse at 
will.  This might be the current XEvIE, or an improved XEvIE (which can 
support multiple clients directly), a cleaner XINPUT (lots of cleaning 
needed to make that nice for end-users to use), or yet still some other 
mechanism.  There has been discussion in the AT hardware world of moving 
to a new USB HID interface for switches and perhaps also tracker 
devices, but that continues to be a fairly long way off I think.  And we 
have a pretty large installed based of devices that look like mice...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.