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

On Fri, 4 Jan 2002, Jon Gunderson 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.

  JRG:  I think we only want current node. We have no real use for bubbling
  information at this point.

CMN I disagree. I don't think it is that much of an accessibility-specific
need to find out where the event is declared - whether it is on the element
or on a parent the point is to know that it can be fired from that element.

  >2) What's the best place to describe the semantics of
  >    author-specified behaviors?
  >
  >Ray has stated that it doesn't make sense to be able to
  >specify descriptions on a per-handler basis if you can't
  >activate handlers individually.
  >
  >Question: Would it be useful for the DOM to provide all
  >descriptions of all handlers for a given event type? Or
  >should we specify instead (one or more) descriptions for an
  >event type (rather than handler)?

  JRG: This seems to be more a markup issue.  The markup language should
  provide a means to associate the purpose/function of a script to a
  particular event handler.  One possible solution is some thing similar to
  the label element for form controls.  This would be considered conditional
  content, form a UAAG point of view, and could be made available to the user
  through the DOM or the User Interface.

CMN Seems sensible to me. When declaring an event handler, and what it
triggers, there ought to be a method for associating a description with the
event.

An example use case might be as follows. Navigating through a page, I find an
item that is active (i.e. it will respond to some event trigger - it might be
identified in a similar way to links being identified, after all they are the
original active elements in HTML). I can query, for example with a context
menu, what are the triggers I can fire here? Ideally, there is a title
associated with each event trigger, for the function that it calls. This
would mean that I could select the trigger to fire from a list of titles,
rather than just guesssing at a behaviour from a specific device I may not
have. Even more ideally, I can ask for a description as well as just a title.
In either case it doesn't seem to matter whether the event is declared on the
element I am interested in, or whether it will be passed through the
capture/bubble mechanism.

In the real world of the legacy content that will persist for a while while
the new ideal system is being adopted, the titles of events will be things
like mousedown, mouseup, keypress, etc, and we are not likely to have a
description for them at first (althugh tehre are a lot of scripts that could
be identified as rollover highlight, or onchange navigation fairly easily, so
if it were very simple to associate an out-of-line decsription, especially
through a mechanism like annotea annotations or out-of-line Xlinks, this
might be done for a useful proportion of pages with a robot.

cheers

Chaals

Received on Saturday, 5 January 2002 00:06:46 UTC