Re: Opening thoughts on WAI-ARIA in HTML5

At 6:59 PM -0500 19 07 2007, Robert Burns wrote:
>On Jul 19, 2007, at 4:31 PM, Joshue O Connor wrote:
>>If [legacy HTML4 accessibility  features]  are supported - and the 
>>spec also supports 'Backward
>>compatibility to ARIA, including the role attribute' then that is one
>>powerful spec - when combined with improved, easy to author, vendor
>>supported, accessibility features. The spec will then both look forward
>>and back. Maybe we should call this the Janus project?
>
>I agree. We have a great opportunity to get accessibility right with 
>HTML5: or improve it drastically anyway.
>
>>>>+ A preference for access to accessibility information via the DOM
>>
>>While this in not a HTML WG issue it is still relevant: This would be
>>ideal - in particular for dynamic content - and it is stated here as a
>>preference.
>
>I think this is an HTML WG issue. After all we are specifying a DOM 
>for HTML5 including UA conformance criteria. One of the problems 
>faced by screen readers and aural browser extensions or aural 
>browsers using general purpose rendering engines (as I understand 
>it) is that sometimes these engines toss out non-visual portions of 
>the DOM. There's no way for extensions to make use of the DOM for 
>aural CSS properties because they're left on the cutting room floor 
>(so to speak). Similar problems could arise for the scope/header 
>algorithm; or for accessing @longdesc  or accessing the contents of 
>an XML <img> element. Just because something is not rendered 
>visually does not mean we cannot provide UA guidance on retaining 
>this information. If its available in from the general UA engines, 
>it can be used by screen readers and  other SDK derived software.
>
>>Many screen readers continue to use the Off Screen Model
>>(OSM). Is it foreseen that most future iterations of screen readers will
>>interrogate the DOM directly and not use the OSM? This is probably
>>likely. AFAIK Dolphins' Supernova is the only screen reader that
>>currently does this. Has the WG contacted any vendors like GW Micro and
>>Freedom Scientific etc to see that they support this shift towards
>>access to accessibility information via the DOM by changing the way
>>their products work?
>
>I think this would be an important place for some evangelism  from our WG.

+1

>I would add Apple to your list (with VoiceOver) too as Apple has a 
>good measure of control over both the screen reader and the web SDK. 
>I'm not sure if the problem with these screen reader vendors is a 
>lack of awareness, or whether their users have expressed an 
>indifference to HTML and CSS specific accessibility features or 
>whether performance optimizations end up tossing out crucial DOM 
>accessibility information. It's a mystery.

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.

AT generally deal with the (OS or language platform) accessibility
API because it saves them developing application-specific code for
those applications that support the API. One of the functions of
WAI-ARIA is to bring the Web applications into the fold of
applications that support these APIs. But AT are using a mix of the
access API, which is usable for both Web content and installed
applications, and the DOM, which contains richer information.

So we are trying to support both; but with the idea that the DOM is
web-standard and at the IDL level common across platforms, to allow
cross-platform development of AT. Then the browser should be
implementing a module that takes the information to the
platform-specific accessibility API for those AT that rely on this,
because the value-add for the AT is still predominated by gaining
access to the installed applications, and not just web content.

I'm basically regurgitating what is in the Roadmap

http://www.w3.org/TR/aria-roadmap

Al


>
>Take care,
>Rob

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