W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2001

RE: Enumeration of EventListeners in DOM Level 3 Events

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Wed, 12 Dec 2001 12:42:51 -0700
Message-ID: <70E215722F6AD511820A000103D141D40AA6DA@thor.aeathtl.com>
To: "'rayw@netscape.com'" <rayw@netscape.com>, Richard Schwerdtfeger <schwer@us.ibm.com>
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
The cross-posting should probably stop, could we move all discussion to
www-dom@w3.org?

Is it a requirement that existing documents can be mined for "commands" that
can be issued or simply that the solution enables new documents can publish
"commands" that could be issued by assistive technologies?

As Ray mentioned, the current proposal would only give you the object
address of the handler and the assistive technology would have to fabricate
appropriate UIEvents by deceiphering from some sort of universal bytecode
reflection on the Java, JavaScript, VBScript, Java, Python, C#, etc,
implementation of the handler.  Without diving into the source code, how
would you know what keystrokes a keydown handler responded to?

It would seem a whole lot simplier to create a CommandQueryEvent that you
could send at an element that would collect event that you could fire to
accomplish some user goal.  This would let documents that wanted to publish
accessible commands could do so.

Something like:

public interface DocumentEvent {
...
   UICommandQueryEvent createUICommandQueryEvent();
   UICommand createUICommand(EventTarget target, Event event, DOMString
name,
	DOMString descriptionURI);
}

public interface UICommandQueryEvent 
{
   //
   //   this would be called during dispatch
   //
   public void addCommand(Command command);
   //
   //    these would be called after dispatch 
   //
   int getLength();
   Command getItem(int index);
}

public interface UICommand
{  
   EventTarget getEventTarget();
   Event getEvent();
   DOMString getName();
   //
   //   this could be some XML resource the describes all sorts
   //     of additional things (VoiceXML, locale-specific descriptions)
   //     about the command
   DOMString getDescriptionURI();
}
   
   
As for intercepting and disabling opening new windows events, I think that
is really an issue of security rights on objects implemented by the browser
and not a DOM issue.  onLoad events could typically be doing very legitimate
things and the nasty things could just move to a different event (like a
focus change).  Ideally, a browser could let assistive technology
participate in determining in the resolution of a window.open() or similar
call.  
Received on Wednesday, 12 December 2001 14:44:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:01 GMT