Confusion over HTML5 & WAI-ARIA

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.

If you are interested in learning about the next generation in Web Accessibility Testing, give Tenon.io a try.
If you or your organization need help with accessibility consulting, strategy, or accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343. Download Resume [MS Word]

2 Trackbacks

Post a Comment