- From: mark novak <menovak@facstaff.wisc.edu>
- Date: Wed, 22 Sep 1999 15:42:40 -0500
- To: "Denis Anson" <danson@miseri.edu>, "Marja-Riitta Koivunen" <marja@w3.org>, <w3c-wai-ua@w3.org>
At 2:48 PM 9/22/99, Denis Anson wrote: >Actually, there are those in the world who could use the "keyboard" language >to make things inaccessible. What we really want is access via character >codes, such as the Control-X code. MN: there are tons of ways to do things, and bypass accessibility. If anything DOS TSR's taught us that ;) However, making all "objects" or perhaps all functions within the application accessible thru the keyboard is the current "default" best case scenario. I'm not telling anyone anything new, and several guidelines refer to this. I also agree with Jon, I think this is old ground for the group, and was just trying to answer Marja-Riitta original concerns. >So long as the UA uses standard system >hooks to get character codes from the keyboard, all is good. MN: Hooks to me, implies "not" using the standard operating system event queue, or "hooking" into it, to steal or alter standard API behavior. This is probably just semantics, but I think other developers might mis-interpret this as well. >But if the >author decides to read the keyboard hardware directly, alternative access >technologies would be cut out. The question is how to phrase the desire for >direct shortcuts via character codes or keyboard events (the Alt key doesn't >have a character code, I don't think, but might be used to control some >types of system events, such as activating the menu bar.) in language that >is unambiguous. MN: The ability for developer's to read the hardware directly is diminshing, but someone, somewhere, will probably always do this. Game developers come to mind. What I see as ambiguous, is any suggestion of not following operating system practice per each platform. >-----Original Message----- >From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On Behalf >Of mark novak >Sent: Wednesday, September 22, 1999 12:43 PM >To: Marja-Riitta Koivunen; w3c-wai-ua@w3.org >Subject: Re: Guideline 2 & device independence > >MN: in theory I agree with alot of what you're saying Marja-Riitta. One >of the things in favor of access, as defined in terms of keyboard access, >is that >voice, Morse, scanning, switch, etc., input methods all get translated into >keyboard events inside the operating system, thus by "default" if an object >is accessible via the keyboard, it should be accessible via these other >methods. > >No guarentees for the future, but any such change would break alot of >software. > > > >At 10:47 AM 9/22/99, Marja-Riitta Koivunen wrote: >>Sorry, but I still think guideline 2 is too device specific when it talks >>about keyboard access. >> >>To understand it better I first explain how I think the system works and >>then what I think we try to say in higher level. >> >>An input device has any number of buttons, maybe location info, microphone >>etc. The computer has a device driver that converts the pushing of buttons, >>saying a word, using morse code etc. to set of events that the user agent >>can understand. When UA gets the events it can activate functions. >> >>Some of the events activate a user level function directly. These are >>shortcuts to the functions and often the event names are related to >>keyboard e.g. "control X". >> >>Often in graphical UI events consist of button pushes and pointer >>movements. The location info of a pointing device is used to decide which >>graphical object should handle the events and activate the functions and >>again the object may use the location info inside to decide which function >>is activated. >> >>So I guess what we want here is to be able to activate functions also >>directly without a need of the pointing information which may be hard to >>create in the device driver with certain non pointing devices. In other >>words we want direct shortcuts to the functionality so that non-pointing >>devices can easily provide that. The fact that the names in the event level >>often come from a keyboard world does not mean we only want keyboard. For >>instance, the "control X" event could be created by the device driver of >>speech device when user says "delete" or creates morse code sequence "-..". >> >>So could we state the GL 2 something like "Provide direct shortcuts to the >>functionality of the user interface (that can be activated by non-pointing >>devices)"? >> >>Then the checkpoints probably need to be rephrased a little but keyboard >>can be used as example. >> >>What do you think? >> >>Marja
Received on Wednesday, 22 September 1999 16:40:59 UTC