exclusive vs. inclusive eventBindingQuery considerations

At 03:19 PM 2002-01-04 , Jon Gunderson wrote:
>Jim,
>A mousedown attached to the body element is usually useless (from an 
>accessibility perspective) since any element in the document can respond to 
>it.  

How do we know it is useless?  We don't know what it does.  And an eventType
only bound on the BODY element could still be exposed as a menu action in the
UI only when there were no more immediate event bindings in the inclusive
query
response.  That's easy enough to do.

One possible counter-arguement goes roughly like this, if I understand the
logic: If there is an action that is accessible by mouseSpecificEvent from the
current context, and the mouse is not usable, why would a context menu
[expanded to accomodate the absense of mouse] not show this action opportunity
in any context where it is intended to be mouseWise activatable?  Maybe it
should be suppressed locally if it makes that menu too busy and there are
other
actions bound more specifically to this context, but there are other ways to
handle that.

One UI option would be to give precedence to events based on the specificity
(to use the CSS term) or locality of binding of the handlers.  Admittedly
capture will override locality of binding, but it is still a plausible
heuristic to use in prioritizing entries in menu-based access to actions. 
Events bearing locally-bound handlers would appear further up in the layers of
a menu tree, and further up within a layer.  In speech output mode menus would
be filtered to seven give or take two items max, with more resulting use of
tree depth.  In speech input and screen output,  wide shallow menu trees would
be used.  The DOM doesn't control this, the UI generator does.

One can still generate a prioritized menu basing priority on the first
occurrence of an event/handler binding coming down the path to the current
context, rather than the last occurrence, even if the boolean simply tells you
"is there a handler declared for eventName in the case that you fire it
here?" 
The UI generator can diff the query responses simply enough and generate this
distinction.

If the DOM responds to the query with exclusive information, it is easy for
the
UI generator to build the inclusive menu including all events bound at any
level along the pathToHere.  And if the DOM response to the query with
inclusive information, it is still easy to generate a filtered or stratified
list, although there is information lost concerning repeated bindings at
different levels to the same eventType.  But it's hard to argue that that
information is critical to the usability of the adaptive UI.  Can the DOM tell
us which of those redundant bindings is the handler that will actually handle
the event?  I think we have been told 'no.'
Given this intrinsic ambiguity, it is not clear whether the inclusive or
exclusive query is better to base a UI hack on.

In the User Agent Working Group debates leading up to saying "just give us the
ones declared here" I for one thought that this was the simplest thing for the
DOM to do, and that we were saying "this would be enough."  Not that we agreed
"this is absolutely necessary."  Ray's argument is plausible and I think we do
need to look at sketches of how one would use the information in a UI
before we
reject the inclusive query out of hand.

Al

>While technically you could test every element and trigger mouse down, 
>this would be a usability nightmare.  That is why UAAG only requires 
>activation of events associated with explicit event handlers of an 
>element.  The event bubbling issue has been discussed in the past [1] and 
>this was our resolution to the problem.  So at least one boolean query must 
>only provide event handler information that is explicitly associated with a 
>particular element (or is it node?).
>
>Jon
>
>[1]
<http://www.w3.org/WAI/UA/1999/06/wai-ua-telecon-19990602.html>http://www.w3
.org/WAI/UA/1999/06/wai-ua-telecon-19990602.html
>
>At 05:45 PM 1/4/2002 +0000, Jim Ley wrote:
>> > Todo: The WAI groups need to provide a use case of when it's useful
>> >   to know that an event handler was declared on the current node
>> >   and not an ancestor.
>>
>>Is this not necessary to make the representation of the events to the
>>user easier, for example, when reaching a body element (say) with an
>>onmousedown event attached, a voice user, may be informed by a prompt
>>that mousedown is possible, you wouldn't then want the UA to prompt on
>>every child node, which is all that a Boolean check would give is it not?
>>
>>Jim.
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Division of Rehabilitation - Education Services
>MC-574
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: <http://www.staff.uiuc.edu/~jongund>http://www.staff.uiuc.edu/~jongund
>WWW: <http://www.w3.org/wai/ua>http://www.w3.org/wai/ua
>

Received on Friday, 4 January 2002 16:39:50 UTC