- From: Ray Whitmer <rayw@netscape.com>
- Date: Thu, 17 Jan 2002 11:20:01 -0800
- To: Al Gilman <asgilman@iamdigex.net>
- CC: "Ian B. Jacobs" <ij@w3.org>, plh@w3.org, lehors@us.ibm.com, shane@aptest.com, gleng@freedomscientific.com, jongund@uiuc.edu, charles@w3.org, w3c-wai-ua@w3.org
Al Gilman wrote: >At the user's option when the focus is at some node the user may query for >"what other actions can I take here?" somewhat analogous to the context menus >supported in many graphical user interfaces. The user is presented with a >range of choices by some dialog, and on user election an event is fired at this >node of some name which the DOM query says is handled when fired at this node, >[Note this is ambiguous as to whether the query returns "event types bound >here" or "event types [prima-facie expected to be] handled when fired here." >The difference is in step 1. > The obvious discoverable choices seem to be: Fire a mouse event with arbitrary coordinates (may or may not work). Fire an arbitrary keystroke (most likely not to produce a desirable outcome, since people usually care which key was pressed, unless it was a generic activation or they may be using this as a way of detecting when a value typed into a field was modified (which should be automatically fired by any agent). I do not understand your use of the word ambiguous. It is certainly not equivalent. In neither case would you have a guarantee that the manufactured event would have a particular desired result, but in the one case, the user is, apparently erroneously, not told that firing an event at this node might be important because it erroneously rules out listeners registered on ancestors. >The current baseline from past deliberations in the UA Working Group for the >maximum set of required navigation stops to use in the above use case is those >nodes where event handlers are explicitly bound at that node. Providing >generalized-tab-sequence navigation over all nodes in the DOM tree was judged >to be so diffuse and slow that nobody would use it, defeating the purpose of >the access to latent actions that this repair functionality is supposed to open >up. > I do not think it is a forgone conclusion that ALL providers will find it problematic. Not permitting users to navigate further if they need to seems to be a mistake, and I would believe that not presenting the options of ancestor nodes once you have navigated down seems to be an error as well. If I were implementing this, I might explore alternatives, since what has been described doesn't sound particularly reliable. For example: The initial tabbed navigation takes users to all roots of hierarchies where specific event handlers of interest declared. If someone has a web page with the perfectly-separated handlers, then they will likely be on the roots of the hierarchies in question. This is the only clean case. Once at a particular node, there might be another navigation keystroke besides tab for more complex pages to enter child nodes, any one of which might also need to have events delivered to it. While it would be cumbersome for someone who was dealing with a simple page to enter child nodes as part of the primary sequence, it would be essential for someone who was dealing with a complex web page. Without it, there is an insurmountable barrier of accessibility. While this approach described thus far does not seem to benefit from querying for which listeners are locally defined, I can see that you might add any node with explicit declarations to the initial tab sequence, even if it did have an ancestor that had already declared them. This would be probably a much-less-common case, but in this one indistinguishable case -- where both a parent and a child have declared a handler for the same event -- I can see that it might be useful. OK. I can buy that this is enough advantage that both modes should be supported. But I think it would be a bad thing once the user navigated to the child, either directly via tab stop or by entering the child heirarchy, to not present all the relevant events that have handlers for that location, including those declared on ancestors. There is nothing in your use case description to indicate that you would want to deny the user this capability and leave such arbitrary barriers to accessibility. >A candidate next-best substitute for that set of nodes, if the DOM will only >tell you "what event types will be handled when fired here" is to do the >functional equivalent of a trace down the path to all DOM nodes, inspect the >boolean-vector-valued "event types handled if fired here" vector and set a >navStop mark on any node where this changes on the pass down the path. Any >node which as a different "event types handled if fired here" property from its >parent would be included in the navStop set, others would be ignored. > It is easy, but does not handle the one case. Still, when presenting the options on a particular node, I think you should present all available on the node, not just those declared at that node, so once you have used this function to create your navstop list, you shouldn't be using it to present options to the user, and I think there should be alternative navigation into at least the child elements of any nav stop, which doesn't get in the way, but permits more complex navigation where it is required, because even if it is less common, events may be expected on the child nodes. >This will give a somewhat smaller set of navStop nodes, but it is "within the >competitive range" of solutions where we should examine the costs and benefits >in more detail. Not to be dismissed out of hand. > >The difference is that nodes whose only eventType handlerBinding is for an >event that has a handler bound further up the tree by another node will appear >under the UA baseline navList specification, and will be absent in the above >candidate which can be produced from the DOM initiated alternate definition of >the handlers? query. Now, clearly if there is a fresh binding for an eventType >bound elsewhere, this is prima_facie evidence that the behavior will be >different in response to firing the event at the lower node vs. the upper >node. So there is high plausibility that adding this particular (eventType, >node) pair to the firings available through the adapted interface is of >substantive benefit. Dunno how often it happens, but there are certainly some >instances of this. So this leaves us inquiring about the cost on the DOM >side. It would seem that a simple syntax-aware response dealing with "what did >the document [and post-load listener registrations?] say?" would not be a great >burden to produce. > Yes, I agree with this. For producing the nav stop list, it solves one more case, that may be less common, but is useful. What has clouded my picture of things in the past is claims that the more-complete query would not be used, whereas it is still clear (to me) that it should be used for the options presented at any node where the user navigates to, IMO. You can manufacture the information by climbing around on the hierarchy, but omitting the complete query might lead vendors to offer incomplete options on the node through neglect rather than through design, whereas having a flag for "all handlers receiving events from this node" versus "only locally-declared handlers" makes it more obvious, I think. >The perceived downsides would appear to be a) it's grody, let's do something >clean, and aligning the scope of the query with the response to firing events >at nodes (Charles's recapitulation of Ray's position). > >I have tried to elucidate the difference in "plausible value added to the user" >for the two different variants on the use case appropriate to the two different >forms of DOM query. Hope this will help us start at a higher point on the >learning curve this afternoon. > Thanks. It has helped me. Ray Whitmer rayw@netscape.com
Received on Thursday, 17 January 2002 14:20:42 UTC