- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 18 Dec 2001 09:32:02 -0600
- To: rayw@netscape.com (Ray 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
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