From HTML WG Wiki
Jump to: navigation, search

Issue: Integration of WAI-ARIA into HTML5

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

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)

  Note: This is high level, but we thought we should say something. We continue to work on some more concrete ideas. None of this is cast in concrete.  But this gives you an idea of where we are coming from.  -- Al Gilman, chair, Protocols & Formats WG (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

*Roadmap for Accessible Rich Internet Applications (ARIA)
*Roles for Accessible Rich Internet Applications (ARIA Roles)
*States and Properties Module for Accessible Rich Internet Applications (ARIA States and Properties)
*Embedding Role and State Metadata into HTML4/XHTML1

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.

  • Note 1: since CLC LISA is proof of concept implementation, there are limitations such as only working on Internet Explorer for Windows; however, it does provide an illustration of how IE can be used to provide ARIA support.
  • Note 2: to try this demo, you will have to allow to run ActiveX for the speech synthesizer. note that no controls will be downloaded nor installed; CLC LISA utilizes SAPI5 which comes with Windows XP and newer. Thus you only need to grant the existing control permission to run.

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

  • Note: this application requires access to a server, preferably Linux based. For the database, it requires MySQL and the scripting language PHP. Refer to the ReefChat Installation page for more details

Other Germane Resources

*AccessibilityDependencies:Accessibility Dependencies of HTMLx
*Evaluation and Repair Language (EARL) 1.0 Schema
*XML Accessibility Guidelines
*Protocols and Formats Working Group (public page)
*Components of Web Accessibility
*Alternative Web Browsing
*How People With Disabilities Use the Web
*Why Standards Harmonization is Essential to Web Accessibility
*Using Combined Expertise to Evaluate Web Accessibility
*References on Web Accessibility

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:


...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
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
instead of
. 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
. 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:

  • It should be possible to use in both (X)HTML and other vocabularies without the need for scripting.
  • The processing should be the same for both HTML and XHTML.
  • It should be possible to author new content that works in Firefox 2.
  • The number of different possible ways to use ARIA should be minimized,and include only variations that are necessary.
  • The proposal should be directly implementable in Firefox 3 and Opera 9.5.

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

   These features provide a standard way to generate an outline for an HTML document. The outline can be used for jumping directly to an interesting part of a long document.


   This element enables a "Skip to content" feature in UAs where the user can't get a quick overview by glance (e.g. aural UAs and visual UAs constrained by a relatively small screen).


   This element lets non-visual UAs indicate to the user that a given piece of text is not part of the main flow of thought. (Failure to indicate this could potentially be confusing.)


   Provides for skipping over administrative information in, for example, aural UAs when the user wants to scan a page as quickly as possible omitting such notices.


   Enables "Skip over navigation" and "Skip to navigation" features in UAs where the user can't easily navigate spatially (non-visual or no pointing device).


   The association of a caption with the element being captioned and the suppression of the caption when a text fallback is used is at least well-intentioned to support the needs of blind readers. Whether the design actually meets these needs is debatable judging from recent comments.


   Makes it possible for non-visual UAs to indicate that a particular run of text was highlighted by, e.g. a search engine, so that a user might want to skip to it. (Again, well-intentioned. Whether it is actually workable is debatable.)


   Provides for AT access to the state of a gauge widget while making it super-easy to make visual gauges that do the right thing AT-wise.


   Hopefully helps the microformat community stop polluting the title="" attribute of the <abbr> element in ways that interfere with the aural Web browsing user experience.


   Provides for AT access to complex grid widgets such as in browser-based email apps like Gmail.


   Provides for AT mapping to the UI idiom that in (for example) the Mac native UI is visually represented by the disclosure triangle.


   Makes it easier for users to fill text fields. Provides for AT mapping to the combobox UI idiom.


   Makes it possible for AT to flag a piece of content as the changing result of a calculation. (I have no idea how useful this is in practice of how aural UAs or screen readers deal with script-based document mutations in general.)


   Provides for AT access to the state of a progress bar widget while making it super-easy to make visual progress bars that do the right thing AT-wise.

Various additions to <input type="">

   Make it easier to adapt input methods to the kind of data the form field asks for. For example, if the field wants a number, a speech recognition input method could restrict itself to trying to recognize numbers only.

The repetition model buttons

   Make it possible for AT to indicate that a given button adds or removes a repeating part (as opposed to indicating a generic button).


   Makes it easy to flag parts of the DOM irrelevant for the current moment in time in the life cycle of a Web app UI view so that AT should not try to present those parts to the user.

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.


HTML5 Element:

   <progress> with a default @role value of "progressbar"



Mac OS X Accessibility Services:

   kAXProgressIndicatorRole CFSTR ("AXProgressIndicator")

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

  *List of built-in accessibility features in the initial HTML5 W3C Editor's draft
  *Proposal to incorporate default value for role for achieving built-in accessibility
  *Henri Sivonen's Table of Built-in role Coverage in HTML5

Tests of Built-in Role Coverage


July 2007

Thread: Opening Thoughts on WAI-ARIA in HTML5

*Opening Thoughts on WAI-ARIA in HTML5 (Al Gilman) (18 July 2007)
     *pointer to built-in role tests (Henri Sivonen) (19 July 2007)
     *Re: Opening Thoughts on WAI-ARIA in HTML5 (Joshue O Connor) (19 July 2007)
     *Re: Opening Thoughts on WAI-ARIA in HTML5 (Robert Burns) (19 July 2007)
     *Re: Opening Thoughts on WAI-ARIA in HTML5 (Al Gilman) (20 July 2007)
     *Re: Opening Thoughts on WAI-ARIA in HTML5 (Maciej Stachowiek) (20 July 2007)
     *Re: Opening Thoughts on WAI-ARIA in HTML5 (Robert Burns) (20 July 2007)
     *Re: Opening Thoughts on WAI-ARIA in HTML5 (Al Gilman) (20 July 2007)

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