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

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


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]