- From: Ray Whitmer <rayw@netscape.com>
- Date: Wed, 12 Dec 2001 09:32:15 -0800
- To: Jon Gunderson <jongund@uiuc.edu>
- CC: Philippe Le Hegaret <plh@w3.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, "Ian B. Jacobs" <ij@w3.org>, w3c-wai-ua@w3.org, www-dom@w3.org
This is what we have needed so we could discuss how completely flawed the current proposal seems to be (to me). What do you want to allow the user to listen to? The binary addresses of handler routines? That is all that the current API provides. No clue about what kind of events the listener accepts or what type of action might be taken. How do you plan to permit the user to invoke these? Trial and error? The API as proposed gives no clue about what types of events should be sent to the handlers it enumerates, which handlers were established by native DOM extensions versus by scripts, or which handlers might be capturing the events of the hierarchy? While the implementation is required to have all of this information, it seems useless to enumerate the listeners if the enumeration does not supply more information about the listeners. One possible solution might be to augment listener registration and enumeration to supply a lot of additional information. However, arguably, other approaches might be more simple for implementers, simple for users and less prone to abuse. It is not necessary to enumerate listeners to fire an event of a particular type at a node. If all you want to know is whether an event would be processed if fired at a particular node, this is a very hard way to get there. In fact, it only answers the question if after producing this implementation the user goes up the tree looking for handlers that might be handling a particular type of event, since events can be captured or bubbled. There are events, which are never user activated, such as mutation events, that should NEVER be manually fired, so having them in the list would be wrong. I think that the questions the accessibility program should be able to ask is something like: If I were to fire an event of type "Key up" on this node, would it be processed? If the answer is true (and it may be due to either the current node or due to ancestors in the hierarchy) then the accessibility program may give the user the option of sending a key press with a particular key. He probably doesn't want to add a dozen different menu uptions for the dozen different listeners registered for the same event. That would break the assumptions of the program were it possible to deliver events without proper capturing, bubbling, preemption, etc. An accessibility program cannot generally fire event types that it does not know because it does not know what type of event to create or what type of parameters need to be filled in, so it seems reasonable to query for specific types. If there were cases that you wanted to cover where there might be a simple generic factory for events which never have parameters (unlike mouse button events or key events, and I cannot think of a good one off the top of my head that would be appropriate to accessibility since non UI events shouldn't be fired in such a scenario anyway), you could make an enumeration function that enumerated the UI (user activated) event types that might be responded to. Perhaps the best way to answer the question is via an event that the listeners respond to. I would also suggest that while we are augmenting the APIs, we might also consider putting a hook for an additional semantic tag if this is a use case we believe in strongly enough. Ray Whitmer rayw@netscape.com Jon Gunderson wrote: > Philippe, > Here are some possible use cases: > > 1. Someon with a visual impairments that uses assistive technologies > (AT) to render web resources through speech output (IBM Home Page > Reader, Freedom Scientific JAWS or GW-Micro Window Eyes) benefit, > since speech output ATs can use the DOM to enumerate the event > handlers and allow the user to listen to the list of possible user > activated events using only keyboard commands. The user could choose > to trigger one of the event handlers from the list using keyboard > commands. In this case it is important for the AT to be able to > figure out what user interface event handlers are associated with each > element in a resource. > > 2. Someone with a physical disability cannot use the standard pointing > device on a browser and uses a plug-in which allows them to to > identify and activate active elements in a web resource. In this case > the plug-in needs to be able to find out which events are associated > with each element. > > 3. Someone with a cognitive disability does not want to have new > windows opened when they load a web resource. By looking for "onLoad" > events a plug-in could be used to filter out or prompt the user before > opening any new windows. In this case the plug-in needs to be able to > find out if there are any on load events and then determine if any of > the scripts associated with the event open new windows. > > Are these the types of use cases you are looking for? > > Jon
Received on Wednesday, 12 December 2001 12:32:53 UTC