Re: in defence of listener discovery (ISSUE-32, ACTION-84)

Hi Al,

It is excellent that we are getting some communication going between our 
groups. I hope we can work something out that we can all be happy with.

Al Gilman wrote:
> * Why in the DOM?
> 
> <quote
> cite="http://lists.w3.org/Archives/Public/public-webapi/2006Mar/0316.html">
> [Jonas, Maciej]
> Actually, my main question is not why the these functions are needed,
> but why they are needed in the DOM API.
> </quote>
> 
> Per the User Agent Accessibility Guidelines, a compliant user agent
> is one that supports the W3C Document Object Model. The reason is
> this is the one API which the W3C controls for which we can prescribe
> interoperability with W3C content. It is from this API that the user
> agent can map secondary API to the DOM or to which the AT can access
> directly for interoperability. Both Home Page Reader, Freedom
> Scientific's JAWS, and the Fire Vox talking web browser all interact
> with the DOM to provide their assistive technology solution.
> 
> It is the DOM that is responsible for getting an event handled by the
> right handler. So it is the DOM that should tell you what that
> handler will be, so that [usability cardinal rule] "the response of
> the system to user action is predictable" when the application is
> operated through a changed profile of input and output modalities.

I think my question still stands. Why do these applications, like JAWS 
and Fire Vox, use the DOM? Since they are external programs and don't 
run in the sandbox of the web page, they should have full access to the 
full set of APIs that the UAs expose where the DOM usually is just a 
small subset.

Is the reason perhaps that it is easy for these tools to use the DOM 
since it is an API that is similar across all UAs? This certainly sounds 
like a valid reason to me if it is the case.

That said, I am not happy about exposing these functions to web pages 
due to privacy and security concerns. If the web page can query which 
EventListeners are registered, and in the future even enumerate and 
query them for information, it could find out information about the user 
that the user might not necessarily want to give out to every site 
he/she goes to. Remember that EventListeners are not limited to ones 
added by the web page. The UA itself could very well be adding 
EventListener to parts of the web page itself. This is certainly the 
case in Firefox where both Firefox itself and various extensions 
installed will add EventListener to parts of the DOM.

However, exposing these functions to web pages does not sound like it is 
a requirement to you, is that correct? If that is the case, but you 
still want an API defined to access this information, maybe we could 
define a separate API specifically for accessibility tools that DOM 
implementations don't necessarily have to expose to web pages.

If we did that I think we would have much greater freedom in adding 
functions since there would be virtually no concern about security, and 
the API could be defined with an entirely different set of users in mind 
(writers of accessibility tools, rather than web developers).

Does that sound like a good solution.

/ Jonas

Received on Thursday, 30 March 2006 09:32:08 UTC