Recently, Everett Zufelt posted an excellent blog post titled: Are You Confused by HTML5 and WAI-ARIA Yet?. In his post, Everett outlines a number of areas in which the evolving HTML5 specification and the WAI-ARIA specification conflict with one another in ways which can cause confusion among web developers. This is especially problematic, in my opinion, because web developers often get things wrong with accessibility and having two things conflict with each other will only add to the confusion.
Two Important Points to Understand
The HTML specification is the shortest path to true accessibility
In the introductory lesson to the Web 2.0 accessibility class I created, I explain the relationship between markup and the objects that get displayed on the screen. It is important for developers to understand that HTML & CSS markup don’t do anything by themselves. Instead they provide instructions to the browser. The Document Object Model (DOM) defines a set of interfaces which the browser uses to create objects which (hopefully) implement all of the properties and methods of the interface. This series of objects is what gets rendered in the user agent. The HTML “tags” and all of their attributes map to an interface which has a specific set of methods and properties, depending on the type of HTML element. For example, let’s take a look at a form input:
interface HTMLInputElement : HTMLElement {
attribute DOMString defaultValue;
attribute boolean defaultChecked;
readonly attribute HTMLFormElement form;
attribute DOMString accept;
attribute DOMString accessKey;
attribute DOMString align;
attribute DOMString alt;
attribute boolean checked;
attribute boolean disabled;
attribute long maxLength;
attribute DOMString name;
attribute boolean readOnly;
// Modified in DOM Level 2:
attribute unsigned long size;
attribute DOMString src;
attribute long tabIndex;
// Modified in DOM Level 2:
attribute DOMString type;
attribute DOMString useMap;
attribute DOMString value;
void blur();
void focus();
void select();
void click();
};Source: http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-6043025
In the block above, we see that HTMLInputElement extends the HTMLElement interface to add additional properties and methods. For instance, it takes additional properties such as ‘checked’ and ‘type’ and also has some additional methods available to it, such as ‘blur’, ‘focus’, and ‘click’. The reason why this is important for accessibility is that conforming browsers will be able to pass through the necessary name, state, role, and value information for the document’s objects to assistive technologies in a way that is meaningful to the user.
WAI-ARIA doesn’t do anything to the DOM
More accurately: WAI-ARIA doesn’t do anything to dictate what type of object is created by the browser. If you create an item on screen which visually looks like a checkbox using <div role="checkbox"> it will be an object created as HTMLDivElement and not HTMLInputElement. Because HTMLDivElement is a generic block container, our simulated checkbox will not enjoy the availability of the properties and methods that it would have if it were a real checkbox. The role attribute and the various aria-* attributes merely become part of the attributes node in the DOM. Consequently, web developers who create simulated controls which utilize WAI-ARIA are on the hook for managing name, state, role, and value for their JavaScript-driven web sites and web-based applications.
Helping to Eliminate Confusion
I am – unquestionably – in love with WAI-ARIA. The more I study it and use it, the more I love it. I view it as the best current tool available for ensuring accessibility in rich internet experiences. It has, however, one very important shortcoming: WAI-ARIA does not change the way the browser creates objects in the document. Developers should always opt to use the most appropriate elements and attributes from HTML, opting to use WAI-ARIA as a bridging technology when markup alone doesn’t expose the necessary accessibility information.
One challenge is that there may be cases where the evolving HTML5 specification isn’t “cutting it” in terms of accessibility. Developers and accessibility advocates should follow and support the excellent work of the HTML Accessibility Task Force who are currently fighting to ensure accessibility in HTML5.