Re: Opening thoughts on WAI-ARIA in HTML5

On Jul 19, 2007, at 8:21 PM, Al Gilman wrote:

> It's no mystery.
> Up until now, browsers have had one processing path to the DOM and
> another to the screen with divergent results.
> Authors only test for what is on the screen. AT would prefer
> information expose through an API like the DOM, but they can only use
> that to serve their customers if it matches what the
> site/application's other customers get, i.e. what is on the screen.
> So consistency of DOM and rendering is something that belongs in the
> UA conformance clauses if you want to advance the state of AT
> practice in this area.

The DOM can't give you complete information about what is onscreen,  
since that is partly under the control of CSS and element-specific  
rendering behaviors. For example, things like  CSS :before/:after  
generated content aren't in the DOM. Neither are the counter values  
for ordered lists.

On Mac OS X, VoiceOver does not use the DOM as the API for  
accessibility hooks into Safari. Instead, the browser (actually the  
WebKit engine) fulfills OS-wide accessibility APIs, and the  
information we present is based primarily on the render tree, but it  
also looks at the DOM.

Overall, I don't think the DOM is the right API for accessibility.  
Assistive technologies need information that is not appropriate to  
expose to scripts in the web page. Also, assistive technologies  
generally work cross-process, which introduces new complexities. And  
finally, to faithfully represent a web page, you need to include CSS  
info, and it's better if the AT can ask the browser how it actually  
rendered things rather than attempting to do its own style resolution.


Received on Friday, 20 July 2007 03:34:02 UTC