- From: Curt Arnold <carnold@houston.rr.com>
- Date: Tue, 11 Dec 2001 10:05:36 -0600
- To: "Richard Schwerdtfeger" <schwer@us.ibm.com>
- Cc: <www-dom@w3.org>
The tension is that if any outside observer can determine the eventListeners attached to an object they could compromise (either by removing or sending fake events) any type of constraint, monitoring or replication service. These would typically be listening to document mutation events instead UI events. I raised this issue in http://lists.w3.org/Archives/Public/www-dom/2001JulSep/0294.html It would be like if a SQL transaction was able to suppress a constraint and then put it back. The ability for an outside observer to compromise any eventListener seemed to contradict the motivation behind eventListenerGroup which provided a mechanism for an eventListener to avoid another eventListener to interfering with the delivery of events. These concerns are more on database uses of DOM than UI uses. There could be a couple of different approaches to satisfy the tension: a) Have an opt-in list, so that an event listener that wishes to be visible would respond to a disclosure request. If the eventListeners disclose themselves, they could provide an object that describes the event. b) Have listeners in non-default eventGroups be able to avoid enumeration. This could be a parameter on the creation of an event group. c) Have only UI events disclosed. ----- Original Message ----- From: "Richard Schwerdtfeger" <schwer@us.ibm.com> To: "Ian B. Jacobs" <ij@w3.org> Cc: "Philippe Le Hegaret" <plh@w3.org>; <w3c-wai-ua@w3.org>; <w3c-wai-ua-request@w3.org>; <www-dom@w3.org> Sent: Tuesday, December 11, 2001 7:56 AM Subject: Re: Enumeration of EventListeners in DOM Level 3 Events > 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. > > 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. > > 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
Received on Tuesday, 11 December 2001 11:07:42 UTC