Re: Enumeration of EventListeners in DOM Level 3 Events

From: "Richard Schwerdtfeger" <schwer@us.ibm.com> wrote:
> It appears that you are complaining about issues that are a direct result
> of the DOM working group including only part of the requirements I had
> placed on you for PF.

Could those requirements be made public or could you provide a link?  (I'm
not a W3C member)  I, like Ray, was very troubled by the current working
draft's proposal in that it seemed to have very obvious negatives but didn't
not seem to be adequate to solve any problems.

> >How does the user select these, by binary address?
>
> Again, when I wrote the requirements for the PF group, I had asked that
the
> event type be available.
>
> >How does the application construct the proper event, by trial and error?
>
> First, an authoring tool ought be able to do this. How might you expect a
> person to create an application without this capability? I also believe
> this may be implementation dependent.

So, say you had an SVG drawing embedded in an HTML page that connected mouse
over in the drawing events with a Java applet and a .NET applet, you'd
expect one accessibility tool to figure out what type of mouse movement you
would need to fake at bring up a specific dialog embedded in one of the
applets.

> >What if the user chooses to invoke functions that should never be user
> >accessible, such as mutation events.
>
> If you new the "type" of event you could selectively pick those which you
> fire. So what might happen if the mutation event was fired. ... probably
> nothing since the application would look to see what changed.

The mutation events contain both the old and new value, spurious mutation
events could have serious side-effects.

>
> >How does the DOM Level 3 script know which event type definition applies
> >to the function, or which listeners must only be invoked in concert?
>
> Another requirement that I had placed on DOM 3 for PF was to be able to
> have a description for each event. Currently, there is no mechanism in
> script to store a description of the event function executed so I when I
> met with PF for DOM 3 I had asked that the function name be stored. Lauren
> Wood thought this was not an unreasonable request at the time.

For non-script event listeners, the method name is always "handleEvent".

>
> These are all fine questions. The bottom line here is that the DOM working
> group only implemented part of the requirements. There is not much I can
do
> about that except that that if DOM 3 needs to be an interim step to where
> we want to go then lets take it. I would love to have had the DOM working
> group include all the PF requirements but you are going to do what you are
> going to do.
>
> What the DOM WG needed to do is:
>
>    Enumerate all events by type
>    For each event provide a description for future script writers to be
>    able to store a text description. For now DOM implementers should store
>    the function name here. (We had discussed this when I met at the face
to
>    face)
>    Allow the user to be able to fire each event based on the information
>    received from the type and description.
>
> What WCAG needs to do is:
>
>    Define industry standard techniques for storing functional descriptions
>    in web content.
>    Come up with standard descriptions for common functions.
>    Document a way for DOM implementers to retrieve them.
>    Work with standards bodies, like that for ECMA script, to hav them
>    accepted.
>
> People working in accessibility have had to fight for every beach head
they
> can get. If the DOM working group implements part of what we asked in
level
> 3 then it is easier to get the rest in 4.

I think everybody that has been involved in this thread is trying to be
helpful.  However, a bad partial solution doesn't help

The key questions that I have are:

a) Is the desire to make it possible for an accessibility tool to make
behavior embedded in hostile web content accessible?  Or is it sufficient to
enable web content that discloses information that can be used by an
accessibility tool?

b) Is the DOM the right place to do this?  Accessibility tools will still
have to mine the HTML content to find content that implies non-script
actions (like submit buttons).  Would it be reasonable to have content
provide non-visible elements that provide accessibility clues?

Received on Tuesday, 18 December 2001 12:02:54 UTC