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.

Accessible practice should probably be that the text is in the
document and switched in and out by CSS.

before: and after: generated content from CSS is an accessibility
hole. Not necessarily a good thing.

>  Neither are the counter values for ordered lists.

Yes, but the counter values are computable from a known algorithm.
Not missing info.

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

Note, what we said was "a preference for info to be in the DOM."
Not "a demand for all info to be in the DOM."  Maybe that
subtlety slipped by.

For example, we *did* put a 'hidden' state in the markup so it is in
the DOM. But not the bounding box. All this is subject to review and
all reasonable proposals will be seriously considered.

>Assistive technologies need information that is not appropriate to 
>expose to scripts in the web page.

Please identify some.

>Also, assistive technologies generally work cross-process, which 
>introduces new complexities.

Not a feature one should seek to preserve.   Are you working to
let the AT run in-process?

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

Obviously, this is a deeper topic worth detailed work. But the
concept of a 'views' layer in the DOM could get the AT the bounding
box etc. that they need.

This is not to dismiss the possibility of segregated API (possibly
DOM) segments for scripting and not-for-scripting but for AT and
other installed applications. Reasonable alternatives. But the more
private layer of info the AT need should still be represented in a
web-wide way. This sounds like enhancements to the DOM. co-programs.

The trick is to get the LOE into WebAPI so the work gets done,
whatever the best shape for it.

>
>Regards,
>Maciej

Received on Friday, 20 July 2007 10:16:41 UTC