- From: Ray Whitmer <rayw@netscape.com>
- Date: Wed, 16 Jan 2002 18:27:44 -0800
- 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 UTC