« An HTML5 Logo | Main | The HTML5 Logo Conversation »
Accessible Rich Internet Applications (WAI-ARIA) moves to Candidate Recommendation (CR)
Today the Protocols and Formats Working Group (PFWG) published WAI-ARIA 1.0 as a Candidate Recommendation. This is a major milestone in development of this technology, indicating that it is considered feature complete after years of development and multiple public consultations. See How WAI Develops Accessibility Guidelines through the W3C Process for more information on public reviews and the Candidate Recommendation process. For an introduction to WAI-ARIA, see the WAI-ARIA Overview.
The PFWG has received approximately 350 comments on WAI-ARIA and its supporting documents since the first Last Call Working Draft of 24 February 2009. These have led to important enhancements to the documents. While the PFWG was not able to accommodate all commenters' suggestions, it did its best to address these within the constraints of WAI-ARIA's design goals and input from many diverse perspectives. The Issue Disposition Report for the publications since the first Last Call show that more than 95% of responses to comments were accepted (or not rejected) by the commenters.
Not every feature that people wished to see is included. To meet accessibility needs on modern Web sites, there is urgent need to deploy a stable, interoperable version of WAI-ARIA 1.0. The features of WAI-ARIA 1.0 represent a good baseline. Various enhancements have been proposed for future versions of WAI-ARIA, including many that were suggested as public comments on WAI-ARIA 1.0 drafts. Because future versions don't require the ground-up engineering of the first version, the expectation is that such features can be incorporated in faster time scales.
WAI-ARIA is intended to be used in multiple content languages, and aspects of its design reflect this. HTML is one of the most important use cases and the PFWG is working closely with the HTML Working Group to provide full integration in a manner consistent with the HTML 5 design. WAI-ARIA is also structured to work with various XML languages and its design reflects this as well. Implementations in such languages are not as mature as HTML-based implementations, but the group expects to see such implementations within the lifetime of WAI-ARIA 1.0.
As WAI-ARIA enters the Candidate Recommendation phase, the focus shifts from specification development to implementation testing. WAI-ARIA is already widely implemented, as prototyping implementations in real tools was an important part of proving efficacy of the features under consideration. Now the PFWG will focus on testing the interoperability and completeness of implementations. The formal goal is to demonstrate implementability of the specification by identifying two or more interoperable implementations of each feature. Another goal, though not a formal requirement for Candidate Recommendations, is to determine how complete implementations are and therefore how useful WAI-ARIA is in practice. If you are interested in helping or have additional comments, please contact us before 25 February 2011. We welcome your help with implementations during Candidate Recommendation!
Filed by Michael Cooper on January 18, 2011 5:12 PM in Accessibility, Publications, Technology, W3Că»Resources, Web Applications
| Permalink
| Comments (3)
| TrackBacks (0)
Comments
Does anyone know the current status of WAI-ARIA and the expected timelines for it to become a Proposed Recommendation?
Michael Cooper 
We are still in the process of building tests and preparing to execute them. It is difficult to provide a good updated timeline estimate for progression to the next stage until we start getting test results in, which should be soon. The Candidate Recommendation Implementations page is the main place we will post progress updates. In particular, we will populate the draft implementation report as test results come in, which will provide the best visibility of status.
Leave a comment
Note: this blog is intended to foster polite on-topic discussions. Comments failing these requirements and spam will not get published. Please, enter your real name and email address. Every individual comment is reviewed by the W3C staff. This may take some time, thank you for your patience.
You can use the following HTML markup (a href, b, i, br/, p, strong, em, ul, ol, li, blockquote, pre) and/or Markdown syntax.
While walking through Loring Park this morning through three inches of freshly fallen snow, I started thinking about the widgets we are making on our current contract and some issues I've had with WAI-ARIA.
One widget used a WAI-ARIA role that was interpreted by JAWS as a tab panel. JAWS took it upon itself to announce that the user should use the arrow keys to navigate the widget. The problem is that the widget wasn't a tabpanel nor could the arrow keys be used to navigate it.
The WAI-ARIA spec should allow the developer to associate key strokes with function and have the screen reader (optionally) read the navigation features of the widget when focus is placed inside it.
As a user of assistive technology tabs through the page or jumps to landmark, if the screen reader is configured to 'read navigation cues', it would speak something like:
'Grid widget. Keyboard Navigation: F5 to refresh. Arrow keys up and down to change rows. Arrow keys left and right to change columns.'
This way, the developer can provide a much better description to the user than having the screen readers guess at what the navigation of a widget is based upon the WAI-ARIA role. While following the design patterns of the WAI-ARIA widgets is a good baseline, the developers should have a means of conveying keyboard navigation of each widget to the screen reader.
I'll post this in the working group and see what people think.
http://enterprisecode.com/blog/?q=Things-Missing-WAI-ARIA