- 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