Issue: Integration of WAI-ARIA into HTML5

Status: Dependency - Integrating Role and State Metadata in HTML5 for WAI-ARIA support.

Quick Links for this page:

Formal Request from the Protocols & Formats Working Group

Integrating ARIA into HTML5: Roles, States and Explicit Markup

Opening thoughts on WAI-ARIA in HTML5 (PFWG)

We look forward to working with the HTML working group on ensuring accessibility support for rich internet applications in HTML 5.

We are finding that developers, are creating countless custom controls in their Web 2.0 applications which require the use of ARIA. ARIA is starting to be incorporated in Web 2.0 applications and widget libraries. Early adopters like IBM, AOL, and SAP are developing ARIA supporting widget libraries like Dojo. ARIA provides needed semantics to enable a user agent to support platform accessibility APIs, allowing for full interoperability with assistive technologies. Furthermore, ARIA addresses keyboard gaps in HTML needed to make these applications accessible. For these reasons it is essential that HTML 5 provide for backward compatability. Vehicles for supporting ARIA states and properties, such as namespaces or a data dictionary linked through the html:html.profile attribute are on the table for discussion.

The working group likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements, such as widgets built in to the markup. This reduces download size and the effort required to make a web page accessible. For these reasons, we would promote the use of such markup over the ARIA approach. That said, we do believe that HTML 5 will not incorporate document elements for all those included in the ARIA role taxonomy nor will it include all the states and properties. For these reasons, backward compatability for the ARIA specifications is a must.

Outside of ARIA we would like HTML 5 to support the XHTML access element. The access element supports badly needed semantics for access key navigation but without the need for device dependency restrictions. Additionally, if accessibility features are being removed from HTML 4.01, such as longdesc or alt text, we need to make sure that the base markup supports the appropriate equivalent functionality in terms of interoperability with assistive technologies. For example, ARIA provides a describedby property which establishes a relationship to descriptive text on the page (prose or text shown in response to a user action) which may be an appropriate alternative.

To summarize, our goals for HTML 5 are as follow:

Related Resources

ARIA Documents and Drafts

Widget Libraries & Toolkits

ARIA & AJAX Examples & Test Suites

The Mozilla Foundation has demonstrated strong support for ARIA, including working with IBM to implement support for ARIA in FireFox; the Mozilla Developer Center contains some excellent introductory and advanced information about ARIA and ARIA Integration into HTML5:

Accessible AJAX test cases by Charles Chen, developer of FireVox and Click,Speak

Becky Gibson, a Web Accessibility Architect at IBM, maintains a personal collection of ARIA and AJAX development resource, named WebA11y

CLC Lightweight, Internet Served Accessibility (LISA) is a project that aims to create a talking browser that is delivered to the user as a web page. There is no application or extension to install; the user simply goes to the CLC LISA web page and is able to use its functions immediately.

The Illinois Center for Instructional Technology Accessibility maintains a suite of ARIA test pages

ReefChat is a free and open source accessible Ajax chat application developed by Peter Thiessen and designed to work with the FireVox screen reader or any other screen reader that supports WAI-ARIA. Features include: accessible layout; ARIA Live Region support; message highlighting based on message importance; message filtering using FireVox screen reader; and chat transcript history (ReefChat gets its name from a coral reef where fish meet to socialize.)

Other Germane Resources

Proposals for Integrating ARIA into HTML5

Ian Hickson's Proposal for Using "aria-" as a Vendor-Prefix in HTML5

It's not clear to me that we want the ARIA roles and attributes at all on the long term. My recommendation would be to use non-namespaces attributes throughout, and to give them some sort of vendor-prefix, as in: 

   aria-required="..."
   aria-state="..."

...and similar. (These aren't namespace prefixes, they're just textual prefixes.) In particular, do not use unprefixed attributes in HTML5, as that will result in conflicts with whatever attributes HTML5 does invent (like "required").

Replies to Ian Hickson's Proposal

Aaron Leventhal

That works for me.

With a "aria-" as the prefix an element can be styled in IE 7 using an attribute selector. Although you can have a colon in an attribute name in IE with text/html, I can't find a way to style that with an attribute selector.

So: 

[aria-hidden] { display: none }        -- works in IE
[aria:hidden] { display: none }        -- doesn't work in IE

Mozilla Developer Center ARIA Relationship to HTML FAQ

Question 11: I want to use text/html with ARIA and avoid declaring namespaces -- what are the current workarounds?

Namespaced role value workaround: One issue that needs a workaround is the namespace requirements in role attribute values. Previously, ARIA's roles require namespaces for the value of the role attribute. For example, it was necessary in Firefox 1.5 and Firefox 2 to use something like <div role="wairole:menuitem"> and of course define both the "wairole" namespace via the xmlns attribute. To make the roles usable in text/html, Firefox 1.5 and 2 hard-coded the meaning of "wairole:" in the prefix. However, the upcoming release of Firefox 3 simplifies this by simply allowing <div role="menuitem"> instead of <div role="wairole:menuitem">. The "wairole:" really served no purpose other than to increase markup clutter and the download size of a web page.

Namespaced property workaround: Fortunately, there is a technique to get around the use of namespaces in the declared markup, so that ARIA can be used in text/html a bit more easily. The technique uses the DOM, specifically setAttributeNS() and removeAttributeNS(), which will apply namespaces even when used in text/html, because it doesn't work any differently based on the original mime type of a document. There is an enable.js library with an onDOMContentLoaded loaded handler that will changes ARIA information encoded in the class attribute and changes it to the the required namespaced properties. For example, it will change <div class="axs checkbox checked"> to <div role="wairole:checkbox" aaa:checked="true">. Currently all major implementors of ARIA in HTML are believed to be using some variation of this technique -- which means, this is the strategy which has been adapted by an overwhelming majority of implementors. Although this hacky workaround is functional, it is not a completely satisfactory technique, and impedes the proper understanding and use of ARIA.

Question 12: That's terrible! What's the proposal to remove the ARIA namespace requirement for properties?

The proposal comes in two parts: For use of ARIA properties in text/html, Ian Hickson has suggested using "aria-" as a prefix for ARIA attribute names. The old method of using setAttributeNS() would still work, however. In the odd case that an author used both on the same element, the real namespaced version would win (because it is always used dynamically after page load, so it's more likely to be the result of user action). This is a very simple proposal to implement in browsers (create a method to get an ARIA property for a node which calls getAttribute, getAttributeNS or both, depending on what's possible in the document). A patch to implement the proposal in Firefox 3 already exists.

Thus far, Ian Hickson, and key individuals within Opera and Mozilla have agreed this is the way forward to make ARIA simpler in HTML. Aaron Leventhal has a working patch for Firefox to allow the hyphenated properties. Implementing these proposals would circumvent the dependency on namespaces (and thus initialization scripts). It would allow ARIA properties to be declared directly in markup, even when used in HTML. This would help increase the ease of adoption for ARIA, by removing a challenging technical barrier, and clarify the process of understanding, documenting, implementing, testing and debugging ARIA support in web applications.

ARIA Proposal (24 September 2007)

I have over the past few days with help from Aaron Leventhal and others written up a draft for how this should work. The goals and constraints we had when writing the proposal were:

The proposal is available at:

The latest version is available at:

Native Accessibility Features of HTML5

Built-in Accessibility Roles in HTML5

It isn't helpful to say that "foo is vital for accessibility" without saying why and what to write as the processing model in the spec in a way that makes sense for the long term (in the case of headers='' so that the processing model also takes into account scope="" as well as implicit "obvious" default association).

<section>, <header> and the outline algorithm

<article>

<aside>

<footer>

<nav>

<figure>

<m>

<meter>

<time>

<datagrid>

<details>

<datalist>

<output>

<progress>

Various additions to <input type="">

The repetition model buttons

irrelevant=""

Chances are that when authoring tool vendors assess business cases, <progress> will have enough of a business case to go with it even without considering accessibility whereas the business case for role="" hinges on accessibility considerations only.

Existing as in "existing in a spec" is not good enough. For something to be considered existing, it needs to be implemented in a way that works. The debates are part of the finding of fact on whether something exists in this latter sense. It is frustrating for those who already know, but it is something we need to go through in order to define processing models that are compatible with the existing implementations.

Related Resources:

Default role Values for HTML Elements and Built-in Accessibility

In an earlier thread, we discussed the ways HTML5 could build-in accessibility by providing commonly used widgets and UI controls that UAs could then map to the accessibility hooks provided by the UA or by the UAs host operating system. That idea had led me to propose doing this with the @role attribute by having a a sensible default @role value set for each element.

One idea that comes to mind from this discussion is that the new Assistive Technology (AT) related elements (like <progress>) might be defined in terms of @role by indicating what the @role value would be by default (and cautioning that it should not be changed except in rare circumstances etc.). I think this would raise awareness about @role and demonstrate its proper use. Its this type of default usage that helps authors understand and properly extend these facilities.

The great advantage of this approach is it still allows simple authoring techniques to accomplish decent accessibility, but it also serves as a pedagogical device by demonstrating how to use the @role attribute for other custom extensions of HTML's semantics. This brings together many of our design principles: accessibility, extensibility, backwards compatibility, etc.

Just to try to provide a more concrete example, consider the HTML5 progress element. By simply adding the @role attribute as a global attribute , we would then specify a default value for each element.

The <progress> element would have a default value of "progressbar". A UA running on Mac OS X (as just an example), would then map any object created with a role of "progressbar" to the Mac OS X accessibility API's role of "kAXProgressIndicatorRole". Since the <[ progress]> element would have this default value for role, it too would be mapped to this.

Summary:

HTML5 Element:

WAIrole:

Mac OS X Accessibility Services:

In this way, the use of role would be there and implemented by UAs without authors doing anything. Authors would not require any knowledge of @role it would simply "just work" behind their backs. However, as a pedagogical device, some authors would notice these @role attributes. As authors made new innovations and created new UI from HTML markup, they could also make use of the WAI role values on their new widgets. UAs would simply need to comprehensively map the WAI role values to their own internal (OS) role values. If HTML5 identified any other roles missing from the WAI vocabulary, we would simply add those to the available repertoire. The @role attribute, all of the WAI role values, and any other role values we felt necessary would all exist in the HTML namespace so there would be no namespace headaches to deal with. Therefore when using role would not require the explicit use of namespaces at all. However, in the xml serialization authors would be free to use other role-value namespaces so long as the targeted UAs support those namespaces.

This to me seems like a big win. This is one of those instances where its hard to think of any disadvantages. To many authors the role attribute would just be there doing its work behind the authors back. Even those authors wanting to make use of role would do so without the need to incorporate namespace declarations. More advanced use in the xml serialization would permit the more advanced approach of incorporating roles from other namespace.

Source: default role values for HTML elements and built-in accessibility (Robert Burns, post to public-html, 2007-07-18)

Supplemental Resources

Tests of Built-in Role Coverage

Email

July 2007

Thread: Opening Thoughts on WAI-ARIA in HTML5

September/October 2007

Thread: ARIA in HTML -- a new FAQ, and a proposal

Thread: ARIA Proposal

Thread: role cardinality

Thread: Vendor Support for XHTML2 [was Re: role cardinality [was Re: ARIA Proposal]]

HTML/ARIAIntegration (last edited 2008-06-24 21:27:08 by GregoryRosmaita)