W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 30 Mar 2006 02:40:02 -0800
Message-Id: <07F1891A-6F5F-4F31-9615-2C97974DE34A@apple.com>
Cc: Al Gilman <Alfred.S.Gilman@IEEE.org>, WebAPI WG <public-webapi@w3.org>, wai-liaison@w3.org
To: Jonas Sicking <jonas@sicking.cc>

On Mar 30, 2006, at 1:33 AM, Jonas Sicking wrote:

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

I'll add that on the Mac, Safari provides accessibility without  
exposing the DOM to assistive software at all. The system screen  
reader and other assistive software tools use general-purpose  
accessibility APIs that Safari implements. So even if this is  
applicable on Windows, it doesn't make sense on the Mac. On Linux  
also there are general accessibility APIs such as ATK.

The real problem is that Windows needs an accessibility API that gets  
implemented in IE and other browsers. I don't think the DOM is the  
right tool for that job, since its primary purpose is scripting in  
web pages.

Received on Thursday, 30 March 2006 10:40:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC