Re: Enumeration of EventListeners in DOM Level 3 Events

Arnold,

PF working group requirements are not public. Making them public is really
up to Al Gilman who chairs the working group.

I understand that you are troubled by the current working draft but don't
be since it is only a working draft and the group is going in the correct
direction.

>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.

My primary concern is JavaScript. JavaScript is probably the single most
frustrating problem for disabled users today and it is on almost every web
page you go to. The scenario you are talking about is so remote I can't
fathom why you would want to bring it up. I can't remember the last time I
used an SVG viewer on the web much less a .NET applet.

However, long term, there needs to be a mechanism for describing what the
function is that you are trying to do. When I co-architected the Java
Accessibility API with sun we provided a mechanism for listing the
accessible actions of an object in Java. Each action had a description and
a pre-defined action. We extended this to a document to be able to
enumerate the list of links available in a document and their description.
The Self Voicing Kit we developed at IBM allowed us to pop up a dialog box
of the functions and have the user select the one they wanted to execute.
It wran outside the application being spoken but the API provision allowed
us to extract the options and allow the user to activate them.

Specifying exactly how you implement each solution (SVG, .NET applet, Java
applet) requires a great deal of long term work that you are not going to
solve today.

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

Fair enough. But to be honest, I don't know why anyone would want to
intentionally fire a mutation event and if they did then let them suffer
the consequences.

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

In most cases this is true.

>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?

I am not sure what you mean by hostile. The problem with "disclosing
information" is that content authors seldom disclose information. Just
getting developers to produce alt-text in documents is difficult.

>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?

Yes, the DOM is the right place to do this. The WAI User Agents Group as
the central mechanism to gain access to accessibility information. The word
"clues" implies that an assistive technology needs to make a guess. I don't
think that's what you mean. You need to explain more about what you mean by
non-visible elements.


>>
>> >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".

Again, the biggest problem today is JavaScript and not plugins or applets.
Typically these are handled separately. However, it would be nice to know
what you needed to do to activate them.



Rich


Rich Schwerdtfeger
Senior Technical Staff Member
IBM Accessibility Center
Research Division
EMail/web: schwer@us.ibm.com

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost



                                                                                                                    
                    "Curt Arnold"                                                                                   
                    <carnold@houst       To:     "Ray Whitmer" <rayw@netscape.com>, Richard                         
                    on.rr.com>            Schwerdtfeger/Austin/IBM@IBMUS                                            
                                         cc:     "Ian B. Jacobs" <ij@w3.org>, "Philippe Le Hegaret" <plh@w3.org>,   
                    12/18/2001            <w3c-wai-ua@w3.org>, <w3c-wai-ua-request@w3.org>, <www-dom@w3.org>        
                    10:53 AM             Subject:     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.

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

In most cases this is true.

>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?

I am not sure what you mean by hostile. The problem with "disclosing
information" is that content authors seldom disclose information. Just
getting developers to produce alt-text in documents is difficult.

>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?

Yes, the DOM is the right place to do this. The WAI User Agents Group as
the central mechanism to gain access to accessibility information. The word
"clues" implies that an assistive technology needs to make a guess. I don't
think that's what you mean. You need to explain more about what you mean by
non-visible elements.


> >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 13:13:30 UTC