W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2002

Re: Next events meeting: 17 Jan 2002 @ 4pm ET

From: Ray Whitmer <rayw@netscape.com>
Date: Wed, 16 Jan 2002 18:27:44 -0800
Message-ID: <3C4636A0.6040701@netscape.com>
To: "Ian B. Jacobs" <ij@w3.org>
CC: plh@w3.org, lehors@us.ibm.com, shane@aptest.com, gleng@freedomscientific.com, jongund@uiuc.edu, charles@w3.org, asgilman@iamdigex.net, w3c-wai-ua@w3.org
I offer the following as my preferred alternative to every proposal I 
have heard to change the markup language with respect to events to make 
pages more accessible.  It addresses short and long term needs:

Define two simple new events:

interface Action:Event {
  readonly attribute DOMString name;
}

interface ActionList:Event {
  void addAction(in DOMString name, in DOMString description);
}

When you want a list of actions on a a target, you fire the ActionList 
event at the target, and listeners list the apropriate semantic actions. 
 Then you put them on the menu.  When the user selects one, you fire the 
Action event with the selected name, and listeners handle the semantic 
actions.

No more broken models, this is a design for the future.  The advantages 
are great:

It is compatible with many different models, such as VoiceBrowser, 
screen readers, and about any other UI I can contemplate, including 
standard web browsers -- I think it would be great to have access to the 
actions of a node from the right-click popup menu on all browsers, and 
the more browsers that display it, the more compelling it is to support 
it in web pages.  For users who are using hardware-generated events, 
there is at last a sensible strategy:  put the semantic part of all 
actions into the semantic handler, and then fire semantic events from 
them as quickly as possible.

It also permits the list of actions to adapt itself to the current state 
of the document.  It permits event handlers to be placed anywhere within 
the path of the current delivery, and when capturing or bubbling events 
at some higher place in the hierarchy, a handler right next to the one 
receiving the action decides which events should have a particular event 
made availabe to them.  This model is relatively perfect, compared to 
the alternatives.

This solves all the problems with no DOM interface changes except the 
events, that any interested implementation can add at any time.  The 
compatibility issues seem manageable, depending upon the details of how 
these are declared which needs to be worked out with the appropriate groups.

With a very good solution for the future in place, I respectfully 
suggest that the only short-term solution we should consider is a 
boolean test for listeners, wherever they may be declared, that receive 
events of a specified type originating on a specified node.  Otherwise, 
as requested previously, please give more specific use cases why more 
than this is essential.

Ray Whitmer
rayw@netscape.com
Received on Wednesday, 16 January 2002 21:28:32 GMT

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