Home

WAI-ARIA finally added to HTML5

Written by Joshue O Connor Friday, 28 August 2009

WAI-ARIA is an incredibly powerful technology that allows developers to easily describe the purpose, state and other functionality of visually rich user interfaces - in a way that can be understood by Assistive Technology. WAI-ARIA has finally been integrated into the current working draft of the HTML 5 specification.

Please note the terms WAI-ARIA and ARIA refer to the same thing. However, it is more correct to use WAI-ARIA to acknowledge its origins in WAI.

Even before it was integrated into HTML 5, WAI-ARIA had already gained partial support in many of the major browsers, most notably IE, Firefox and Opera. It also gained support in the more commonly used screen readers such as JAWS, Window Eyes and the excellent (and free), NVDA.

"For a really interesting overview of current screen reader support read Marco Zehe of Mozilla’s excellent ‘WAI-ARIA Windows screen reader shootout’ article".

Born out of DHTML

WAI-ARIA was originally a bridging technology that came out of the WAI DHTML Roadmap. This initiative arose out of the very practical need for addressing the inaccessibility of much dynamic web content for people with disabilities. This came at a time where more Web 2.0 developers were using Javascript more and more, as well as coming up against the inherent limitations in HTML 4 when building dynamic applications with rich user interfaces. It was often very difficult to make these applications accessible. Some of the main issues were:

• Accessibility is dependent on abstracting semantics from both content and presentation information. Extracting these semantics from HTML content was not reliable.
• HTML allowed content to be re-purposed for presentation formatting without providing a way to convey this information. A common example of this is the use of tables for formatting content as opposed to style sheets.
• HTML, when combined with script and CSS, may be re-purposed to create dynamic custom components without the ability for the author to convey this information to the native accessibility architectures designed to support dynamic GUI content.
• HTML lacked the ability to attach meaningful meta data about document structure.

So what to do?

The DHTML Roadmap aimed to look at the semantic gap that obviously existed and thereby develop a flexible toolkit that developers could freely use now to provide the semantic hooks needed to develop accessible interfaces.

But hang on, I hear you say, isn’t the markup language supposed to provide these semantics in the first place? Yes it is, but HTML was primarily designed as a document markup language, not the scaffolding for rich user interfaces and dynamic content.

While this roadmap was being put together, HTML 5 was still very much in early stages. HTML 5 was being developed from scratch and there were naturally all the delays inherent in specification writing. There was a solution needed immediately that could work with existing markup languages. So WAI-ARIA was born.

What does WAI-ARIA code look like?

Here are some examples of what WAI-ARIA code looks like and what you can do with it:

To set landmarks roles on a semantically neutral <div>

<div role="log" title="chat log">
<div role="region" title="Game Statistics">  

For application landmarks with static prose

If you have a regional landmark of type application and static descriptive text is available, then on the application landmark, include an aria-describedby reference to associate the application and the static text as shown here:

<div role="application" 
aria-labelledby="calendar"
aria-describedby="info">

<h1 id="calendar">Calendar<h1>
<p id="info">
This calendar shows the game 
 schedule for the Boston Red Sox.
</p>
<div role="grid">
....
</div>

Static Table of Contents Directory

The ARIA role, directory, allows authors to mark static table of content sections of a document. Prior to ARIA, the user would need to guess if an area of a document actually pertained to the table of contents. Authors should mark these sections within a document with a role of directory.

<div role="directory">

<ul>
<li>Global Warming Causes
<ul>
<li>CO2 Buildup</li>
<li>Auto emissions</li>

<li>Factory emissions</li>
<li>Destruction of rainforests</li>
</ul>

</li>

<li>Tailoring CO2 buildup
<ul>
<li>Elimination of the incandescent
 light bulb</li>
<li>Hydrogen fuel cells</li>

<li>Solar energy</li>
<li>Wind power</li>
</ul>

</li>
</ul>

</div>

There is a lot of other cool stuff that WAI-ARIA can do such as allowing the developer to set the required fields on a form (no more useless asterisk) in a much more reliable way, or alerting the user when maximum field length has been reached on input controls, or simple focus changes after user input to enhance usability. And that is before we touch on the incredibly useful aria-describedby and aria-labelledby or how WAI-ARIA is improving the accessibility of your favourite Open Source Content Management Systems (CMS).

WAI-ARIA is a nice polite technology in that it will not cause errors in user agents that do not support it, so no crashes or freezes, or people just not being able to access some, or all, of your application. WAI-ARIA is a host agnostic language, meaning it can be plugged into many languages such as HTML, XHTML, SVG - with the same syntax - and is recognized by the user agents that support it and just ignored by those that don’t.

All excellent. And also only the tip of the iceberg. However, is it really that simple?

Strong vs. Weak vs. Implicit Semantics

When developers start adding WAI-ARIA role, states and properties mark up to built smart widgets and controls, this would generally take one of two forms. Adding this extra markup to a semantically neutral <div> or to existing markup like anchors element, or form controls in HTML markup.

So, the <div> elements have no semantic properties at all so this is why we can easily add the ARIA markup without to much ado, I hear you cry? Well, yes. But don’t many HTML elements have their own inherent semantics? Well, yes. So could there be a clash between what the ARIA role is trying to describe and the inherent semantics of the host elements? Well, yes.

So how does HTML 5 propose to deal with this issue? What would user agents do in these scenarios and are their other potential problems these kind of conflicts could cause?

Some of the Issues, as outlined by WAI’s Michael Cooper are:

• Existing host language features should not, in theory, be reclassified with ARIA roles.
• Defining the processing model for such situations:

  <input type="checkbox" role="radio" />

  was presented as a frequent example, or because the host language element is semantically similar to an ARIA role and should be used for that purpose without reclassification.
• Host languages evolve and provide features that previously authors could only achieve with repurposed elements.
• Legacy content may include ARIA repurposing of elements that would not be required in newer content using the updated host language.

So the idea of ‘implicit ARIA semantics’ was born to deal with some of the more foreseeable situations where a conflict is likely to occur.

Overriding HTML semantics with ARIA

In the new section of the HTML 5 specification that deals with WAI-ARIA (Annotations for Assistive Technology Products), the spec states that some HTML elements have semantics that can be overridden, these include the new HTML 5 elements such as <article>, <aside>, <section> and existing elements that will be familiar from HTML 4 such as <li>, <ol> and <ul>.

Don’t worry if you are not familiar with these new HTML 5 elements, they pretty much do what they say on the tin! The same applies to the ARIA role markup. You are just describing literally to Assistive Technology what the purpose or role or state of the current element (or indeed the entire widget is).

The <article>, <aside>, <section> elements have the following applied semantics ‘article role’, ‘note role’ and ‘region role’ and the <li> element (whose parent is an <ol> or a <ul> element has the ‘listitem role’ and where that is not the case the <ul> and <ol> elements both have the implied semantic of a ‘list role’.

So what are the inherent semantic restrictions? The specification defines that where ARIA is applied to any of the above HTML elements they must have the following roles:

• An <article> element Role must be either article, document, application, or main
• An <aside> element Role must be either note, complementary, or search
• A <section> element Role must be either region, document, application, contentinfo, main, search, alert, dialog, alertdialog, status, or log

I hope it may now be a bit clearer to you why there is potential for conflict with these elements. If not, there is an interesting post by Operas Anne Van Kesteren that discusses role duplication, and Jeremy Keith has some interesting related links from his post 'Ariability'. There are other knock on effects of changing an elements role and that is with the host elements corresponding states and properties that are also potentially effected by the role change - but that’s a discussion for another day.

Applying these constraints to how host elements should behave when ARIA roles are applied gives a clearer content model to determine how the user agents should perform when the markup just goes wrong, or when developers come with new creative ways of marking up their content (as they are want to do). So this is a very exiting development to see WAI-ARIA finally make it in the HTML 5 specification and while there are details to be ironed out (and some very interesting issues that I hope I have given you a glimpse of) it is fascinating to track the semantic struggle that will enable the power of HTML 5 and flexibility of WAI-ARIA to co-exist and compliment each other in a positive dynamic way.