- From: Ray Whitmer <rayw@netscape.com>
- Date: Sat, 23 Feb 2002 04:12:50 -0800
- To: w3c-wai-ua@w3.org
Sorry, scrambling to respond to the last few messages. >1. Point of possible agreement. In the oral discussions on the 17th, I >thought that there was some agreement that "name" as what comes back in the >list of events could be replaced with "description" as a friendly amendment, so >far as the DOM implementation is concerned, so long as the description is there >for the DOM to grab from somewhere, and it doesn't have to make it up. > As described in the proposal I made earlier, this event supports adding the name and description of the event, so I don't see that an ammendment is needed (yet). According to the proposal, the DOM needs to grab nothing. The ActionList event can/should be standardized by the Events specification, but need not be implemented by a particular DOM to be usable, because any accessibility agent can create and fire the event on existing DOM's today. >2. Point of possible disagreement. Some opinion was voiced, I believe, to the >effect that we simply aren't interested in firing events that go with devices >not in use. I would disagree. Populating event data by algorithm, heuristic, >and dialog is something that assistive technology might indeed take on. >Knowing what you have to produce may influence what the approach is. Compare >with the "mouse grid" method of arming active elements in a scene used in voice >command. Here it matters that the objective is to isolate an active element. >Voice input into MouseKeys would be much more indirect and tedious. So >creating a virtual rubber band by progressive refinement is a better approach. > As I understand what you have stated, I do not know who would have voiced this opinion. The whole point of the two new methods on the DOM Level 3 events draft is to provide accessibility agents with a way of synthesizing events for devices not in use, I believe. My only assertion is that AT cannot and should not fire events, the meaning and construction of which it does not understand. This understanding must typically reside in the AT. If it wants to fire mouse events, then it tests for listeners, constructs them appropriately, and then fires them. The same goes for any other device such as keyboard. These event structures are well-enough understood to fire, as long as it knows the structure, and fires them in the documented way, using the dispatch methods supplied for that purpose. >What I don't know is the status quo on this point. How do scripts know what >data they can look for in an event? Or do they just query system state? If >the pointer location is something the script needs, does it get it from the >event or from the environment? How would an assistive software routine with >DOM access take the name of an event type and learn the data structure >characteristics of that event type? > You assume machine introspection not in existence. No part of any DOM API permits reflection of the data involved, and if a language such as Java did, it is a large step between knowing the data types and knowing the meaning. The specification is there to tell any clients of the technology what event types are available, and the AT should use those that are appropriate, not try to discover every possible event, many of which it would be harmful to expose to any user, because they are not even UI events. Specifically handling the appropriate set of events will get you much further than trying to discover and fire events, the type of which the AT provider hasn't bothered to support. Browsers do not just arbitrarily add UI events. If they did, no script would use it. Standard event types are a good, known qwuantity. >The high-end response, here, would be to recommend that events in XML use the >'model' module from XForms, or some schema discipline like that, to introduce >XML-native definitions of the events that pass through the environment of an >XML document, and to which the XML document attaches associations. This would >establish a common basis of understanding between script writers and the >writers of assistive interlopers and the delivery context bindings that also >manipulate these events. > Script writers do not typically produce new event types. AT suppliers are free to describe events in any way they wish, but there is nothing additional that is useful to be discovered about the event type from the script writer. I highly recommend that AT suppliers stick to UI events that are intended to be fired by user intervention. Interfering with non-UI events (besides semantic events designed for that purpose) is a recipe for program malfunction and user frustration. >Is this functionality already implicit in the status quo? If so, how does it >work? > You have not presented a case where such would be useful. I think discussing a concrete case might help us both think more clearly about the issue. Ray Whitmer rayw@netscape.com
Received on Saturday, 23 February 2002 07:13:26 UTC