Hi Chris, > On 17/08/06, Bill Haneman <[EMAIL PROTECTED]> 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. _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
