while i am biased towards early ARIA adaptation, having worked on the ARIA spec for longer than i'd care to remember, i would counsel both early adaptation AND redundancy for graceful degredation, for, as everett has consitently and correctly pointed out, implementation of ARIA is incomplete and inconsistent... second, ARIA is intended to be a bridging technology, not a panacea for all accessibility problems or issues, but a means of filling those perceptual and functional black holes that scripted content often causes; it has always been the stance of the PFWG that whilst it is of utmost importance that ARIA markup be supported (or at least "allowed") in markup languages, native solutions -- if extant -- are vastly preferable, as they are more likely to be available to the user sooner, with less effort on the developer's/author's side, and more consistently...
the ARIA sub-group of the W3C's PF (Protocols & Formats) working group (which owns the deliverable) aims to have a what it hopes to be a new Last Call draft by mid-May, although i should also point out that the ARIA editor's drafts are also available to the public:
- ARIA editor's Draft: http://www.w3.org/WAI/PF/aria/
- ARIA User Agent Implementation Guide, 1.0: http://www.w3.org/WAI/PF/aria-implementation/
- ARIA 1.0 Roadmap
- ARIA Primer: http://www.w3.org/WAI/PF/aria-primer/
- ARIA Best Practices Guide: http://www.w3.org/WAI/PF/aria-practices/
the first 3 listed are the ones upon which work has been most intense, and i estimate that the ARIA sub-group will publish at least 2 more editor's drafts before the final editor's draft is submitted to the W3C as a Last Call document; currently our target timeframe for submission of a Last Call draft to the W3C is mid-May 2010.
[explanation of W3C process & nomenclature: Last Call is the stage of W3C process where the public has a final chance to comment upon the draft and suggest changes; once ARIA leaves "Last Call" it will enter the "Candidate Recommendation" (CR) stage, a time where 2 independent implementations of each aspect of ARIA need to be documented (note that this does not mean full implementation of ARIA by one entity, but that all of the elements of ARIA have been implemented at least twice by someone/something); after CR, the draft will enter "Proposed Recommendation" status, which means that it has been vetted by the community, the PFWG has responded to all comments, closed all issues, and resolved any problems or inconsitencies -- the only thing that separates PR from TR ("Technical Recommendation") is that in order to become a Technical Recommendation, a document has to be approved by the W3C's membership and advisory committee. (for more detail on W3C process than you ever wanted can be found at: http://www.w3.org/Consortium/Process/ and http://www.w3.org/WAI/intro/w3c-process/]
moving forward, getting ARIA into Drupal without having Drupal become reliant on ARIA is also of utmost importance -- by paving the way, using native solutions where possible, and ARIA where needed due to the shortcomings of the underlying markup language(s), Drupal can be a key contributor to the overall success of ARIA, and can play a major role in determining how ARIA is best integrated into a wider accessibility strategy...
PS: The ToDo list for ARIA 2.0 is already quite large and growing