Re: Enumeration of EventListeners in DOM Level 3 Events

Ray,

It appears that you are complaining about issues that are a direct result
of the DOM working group including only part of the requirements I had
placed on you for PF. What would you have me say? Stop shooting yourself
with the arrows?

>How does the user select these, by binary address?

Again, when I wrote the requirements for the PF group, I had asked that the
event type be available.

>How does the application construct the proper event, by trial and error?

First, an authoring tool ought be able to do this. How might you expect a
person to create an application without this capability? I also believe
this may be implementation dependent.

>What if the user chooses to invoke functions that should never be user
>accessible, such as mutation events.

If you new the "type" of event you could selectively pick those which you
fire. So what might happen if the mutation event was fired. ... probably
nothing since the application would look to see what changed.

>How does the DOM Level 3 script know which event type definition applies
>to the function, or which listeners must only be invoked in concert?

Another requirement that I had placed on DOM 3 for PF was to be able to
have a description for each event. Currently, there is no mechanism in
script to store a description of the event function executed so I when I
met with PF for DOM 3 I had asked that the function name be stored. Lauren
Wood thought this was not an unreasonable request at the time.

These are all fine questions. The bottom line here is that the DOM working
group only implemented part of the requirements. There is not much I can do
about that except that that if DOM 3 needs to be an interim step to where
we want to go then lets take it. I would love to have had the DOM working
group include all the PF requirements but you are going to do what you are
going to do.

What the DOM WG needed to do is:

   Enumerate all events by type
   For each event provide a description for future script writers to be
   able to store a text description. For now DOM implementers should store
   the function name here. (We had discussed this when I met at the face to
   face)
   Allow the user to be able to fire each event based on the information
   received from the type and description.

What WCAG needs to do is:

   Define industry standard techniques for storing functional descriptions
   in web content.
   Come up with standard descriptions for common functions.
   Document a way for DOM implementers to retrieve them.
   Work with standards bodies, like that for ECMA script, to hav them
   accepted.

People working in accessibility have had to fight for every beach head they
can get. If the DOM working group implements part of what we asked in level
3 then it is easier to get the rest in 4.

Rich





Rich Schwerdtfeger
Senior Technical Staff Member
IBM Accessibility Center
Research Division
EMail/web: schwer@us.ibm.com

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost



                                                                                                                    
                    rayw@netscape.                                                                                  
                    com (Ray             To:     Richard Schwerdtfeger/Austin/IBM@IBMUS                             
                    Whitmer)             cc:     "Ian B. Jacobs" <ij@w3.org>, Philippe Le Hegaret <plh@w3.org>,     
                                          w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org, www-dom@w3.org              
                    12/12/2001           Subject:     Re: Enumeration of EventListeners in DOM Level 3 Events       
                    11:39 AM                                                                                        
                                                                                                                    
                                                                                                                    



Richard Schwerdtfeger wrote:

>Ian and Philippe,
>
>Fantastic!
>
>From an authoring tools perspective this is very useful. It allows a
>content developer to programmatically exercise the listeners individually
>so this has advantages to disabled as well as non-disabled users.
>
>From a disabled user perspective, the input device used to simulate the
>activate of each listener may be voice recogntion or some other
specialized
>input device such as an onscreen keyboard combined with:
>
>   big switch
>   specialized keyboard (Don Johnston)
>
>Assistive technologies such as HPR could enumerate the listeners and allow
>the user to select which one to activate. This would aid with users
>creating web sites as well as accessing them. From a UI perspective a
>pop-up window showing the available functions to be executed in response
to
>each event could be activated allowing the user to hear and speak which
one
>to be activated ... and then of  couse activate the appropriate one.
>
How does the user select these, by binary address?

How does the application construct the proper event, by trial and error?

What if the user chooses to invoke functions that should never be user
accessible, such as mutation events.

>If the WCAG group could do more with Script (require addition of function
>descriptions) it would be nice to have the ability to store the function
>description executed in response to a given event in which case a script
>developer could create a function description for those functions executed
>in response to an event that could be stored and access through the DOM.
>Currently DOM 3 is limited to providing the type definition. ... Perhaps
>for DOM 4 we could add this.
>
How does the DOM Level 3 script know which event type definition applies
to the function, or which listeners must only be invoked in concert?

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 18 December 2001 10:32:17 UTC