HTML5 and the myth of WAI-ARIA redundance

Will HTML5 make the use of WAI-ARIA in HTML redundant? the short answer is definitley not. There are many ARIA roles and properties that are not provided by native elements and attributes in HTML5. Also developers still have the desire to roll their own interactive controls even though they have been available in HTML as native elements for 11 years, why would this suddenly change when HTML5 arrives?

Examples: a button and a link

Developers have had for 11 years number of native elements they can use for buttons and the a element for links, provided in HTML 4, all of which provide built in mouse and keyboard interaction and convey role, state and name properties to accessibilityAPIs:

input type="button"
input type="image"
button element
a element

But still in 2010 companies like Google, choose to emulate a button with code (not to mention the associated scripting) such as this:

<DIV id=:rk class="J-K-I J-J5-Ji L3 J-K-I-JO" tabIndex=0 unselectable="on" closure_hashCode_l16mgm="182" act=""> <DIV class="J-J5-Ji J-K-I-Kv-H" unselectable="on"> <DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on"> <DIV class=J-K-I-KC unselectable="on"> <DIV class=J-K-I-K9-KP unselectable="on"> </DIV> <DIV class=J-K-I-Jz unselectable="on">Search Mail</DIV> </DIV></DIV></DIV></DIV>

and a link like this:

<SPAN id=:rg class=toxOdd role=link tabIndex=0 closure_hashCode_l16mgm="177"> Create a filter</SPAN>

Note: Examples are taken from Googles Gmail application.

The reason is probably because they cannot apply the styles they want to native interactive elements, but who knows? What is important for accessibility is if developers choose to code in this way, they now have a method to provide the needed accessibility information. It would be preferable that they used the available native HTML elements, but if they do not, then ARIA provides what HTML alone cannot.

Aria roles and properties not available in HTML5

Below are listed the ARIA roles and properties. Those roles and properties suffixed with a “+” are features not considered to be available natively in HTML5. It is clear that many roles and properties provided by ARIA which can be used to convey information to users are not available in HTML5.

ARIA Roles

5.3.2. Widget Roles

The following roles act as user interface widgets that do not provide a defined structure. All roles are linked to their definitions in the WAI-ARIA 1.0 specification.

The following roles act as composite user interface widgets that provide a defined structure. These roles typically act as containers that manage other, contained widgets.

5.3.3. Document Structure

The following roles describe structures that organize content in a page. Document structures are not usually interactive.

5.3.4. Landmark Roles

The following roles are regions of the page intended as navigational landmarks.

ARIA States and Properties (all aria-* attributes)

Below is an alphabetical list of WAI-ARIA states and properties to be used by rich internet application authors. A detailed definition of each WAI-ARIA state and property follows this compact list.

aria-activedescendant +: Identifies the currently active descendant of a composite widget.
aria-atomic +: Indicates whether assistive technologies will present all, or only parts of, the changed region based on the change notifications defined by the aria-relevant attribute. Also see aria-relevant.
aria-autocomplete: Indicates whether user input completion suggestions are provided.
aria-busy (state) +: Indicates whether an element, and its subtree, are currently being updated.
aria-checked (state): Indicates the current “checked” state of checkboxes, radio buttons, and other widgets. Also see aria-pressed and aria-selected.
aria-controls +: Identifies the element (or elements) whose contents or presence are controlled by the current element. Also see aria-owns.
aria-describedby +: Identifies the element (or elements) that describes the object. Also see aria-labelledby.
aria-disabled (state): Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. Also see aria-hidden and aria-readonly.
aria-dropeffect +: Indicates what functions can be performed when the dragged object is released on the drop target. This allows assistive technologies to convey the possible drag options available to users, including whether a pop-up menu of choices is provided by the application. Typically, drop effect functions can only be provided once an object has been grabbed for a drag operation as the drop effect functions available are dependent on the object being dragged.
aria-expanded (state) +: Indicates whether an expandable/collapsible group of elements is currently expanded or collapsed.
aria-flowto +: Identifies the next element (or elements) in the recommended reading order of content, overriding the general default to read in document source order.
aria-grabbed (state) +: Indicates an element’s “grabbed” state in a drag-and-drop operation.
aria-haspopup +: Indicates that the element has a popup context menu or sub-level menu.
aria-hidden (state): Indicates that the element is not visible or perceivable to any user. Also see aria-disabled.
aria-invalid (state): Indicates the entered value does not conform to the format expected by the application.
aria-label +: Defines a string value that labels the current element when included as an attribute of the current element. Also see aria-labelledby.
aria-labelledby +: Identifies the element (or elements) that labels the current element. Also see aria-label and aria-describedby.
aria-level +: Defines the hierarchical level of an element within a structure.
aria-live +: Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and user can expect from the live region.
aria-multiline: Indicates whether a text box accepts only a single line, or if it can accept multiline input.
aria-multiselectable: Indicates that the user may select more than one item from the current selectable descendants.
aria-orientation +: Indicates whether the element and orientation is horizontal or vertical.
aria-owns +: Identifies an element (or elements) in order to define a visual, functional, or contextual parent/child relationship between DOM elements where the DOM hierarchy cannot be used to represent the relationship. Also see aria-controls.
aria-posinset +: Defines an element’s number or position in the current set of listitems or treeitems. Not required if all elements in the set are present in the DOM. Also see aria-setsize.
aria-pressed (state) +: Indicates the current “pressed” state of toggle buttons. Also see aria-checked and aria-selected.
aria-readonly: Indicates that the element is not editable, but is otherwise operable. Also see aria-disabled.
aria-relevant +: Indicates what user agent change notifications (additions, removals, etc.) assistive technologies will monitor within a live region. Also see aria-atomic.
aria-required: Indicates that user input is required on the element before a form may be submitted.
aria-selected (state): Indicates the current “selected” state of various widgets. Also see aria-checked and aria-pressed.
aria-setsize +: Defines the number of items in the current set of listitems or treeitems. Not required if all elements in the set are present in the DOM. Also see aria-posinset.
aria-sort +: Indicates if items in a table or grid are sorted in ascending or descending order.
aria-valuemax: Defines the maximum allowed value for a range widget.
aria-valuemin: Defines the minimum allowed value for a range widget.
aria-valuenow: Defines the current value for a range widget. Also see aria-valuetext.
aria-valuetext: Defines the human readable text alternative of aria-valuenow for a range widget.