Re: access to machine comprehensible type information for events?

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