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:

search mail button.

<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">&nbsp;</DIV>
<DIV class=J-K-I-Jz unselectable="on">Search Mail</DIV>
</DIV></DIV></DIV></DIV>

and a link like this:

Create filter link.

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

Further reading:

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.
Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

Shelley says:

Excellent. Timely. It would also help if accessibility folks would stop using terms such as “bolt on” and “stop gap”, when talking about ARIA. We developers are getting a very confusing, very mixed, message.

Even the use of “bridge” isn’t necessary. It should be sufficient to just say: you can incorporate accessibility into your applications using existing HTML elements that have integrated accessibility, or you can incorporate WAI-ARIA into your web pages and JavaScript applications…or both!

We can’t told to use WAI-ARIA and not to use WAI-ARIA at the same time and still be expected to know what we should do.

John says:

Thanks for the review Steve. My hope is that developers continue to *add* (or bolt-on) these attributes to their meaningless , to ensure that when they get creative with form inputs, etc. (as witnessed by your button example above, which *could* have been rendered with the more ‘semantic’ and meaningful by using the

I take exception to Shelley’s comment, as it completely ignores history and the actual design intent of ARIA, which was developed (starting close to a decade ago) to retro-fit content that was inaccessible for a variety of reasons. As a retro-fit solution, it is *very* clever and well done, but as it still requires additional effort and code on the part of the author, it is less optimal than using specific native elements which require no additional effort on the author’s part to convey meaning; again we can return to

Including WAI-ARIA support does require a little extra effort, yet it is not significantly more than usual development. For those developing static Web pages or using libraries with WAI-ARIA built in, implementing WAI-ARIA is fairly straightforward. Developing custom, cross-browser JavaScript widgets is more complex, and implementing WAI-ARIA in these is proportionally more complex. https://www.w3.org/WAI/aria/faq

It is less than helpful to the accessibility cause to have late-comers show up and start telling those who have worked in the field for years (including some of the biggest and brightest stars, including Rich Schwerdtfeger (IBM Distinguished engineer), TV Ramen (Google, developer of Emacspeak), James Craig (Apple), and countless others) that they are wrong. Further, to go onto blogs and tell that community that quoting from the ARIA document is inappropriate does the accessibility community a real disservice. From the ARIA Draft:

WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page. This is important because the invention of new types of objects is faster than standardized support for them appears in page languages.

It is not appropriate to create objects with style and script when the page language does provide semantics for that type of object. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively.

It is expected that, over time, host languages will evolve to provide semantics for objects that previously could only be declared with WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature. Legacy content may continue to use WAI-ARIA, however, so the need for user agents to support WAI-ARIA remains. https://www.w3.org/TR/wai-aria/introduction#co-evolution

Frankly Shelley, please stop spreading mis-information; you are helping no-one, and hurting many simply to drive your political agenda. If you beleive that the ARIA Working Draft is incorrect, you might still be able to add your feedback, although the deadline for submissions was February 2010. It’s really too bad your interest in ARIA doesn’t go back that far, as if your observations were valid, they could have been addressed prior to that date in the appropriate forum.

Totally agree Steve. I’ll also add that ARIA will likely expand in the future and it can provide a way to more rapidly add new roles that may be needed. ARIA defines some roles that the Flash Player already supports, so when the Flash Player and Flex add support for IA2 and ARIA we may not need to use all of the roles for our accessible components, but developers will need ARIA to support some additional control types, and the need for the liveRegion functionality is also critical.

If anyone is thinking that HTML5 will obsolete ARIA they are kidding themselves.

Roger Hudson says:

Many thanks, timely and the use of the word ‘myth’ in the title very pertinent. For me ARIA is accessibility value-adding, and as support increases so will the use of ARIA. BTW, when will HTML 5 arrive, we can’t sit on our hands and do nothing until it arrives – Waiting for Godot.

David Bolter says:

Steve – Awesome. I’m glad you realized the need for this blog and did it.

John – I’m glad you to see you give specific props to Rich Schwerdtfeger, he has been a tireless leader in making ARIA a real world solution.

Andrew – looking forward to IA2 support in Flash and Flex!

Allen Hoffman says:

This is an excellent article. Keep them coming. Understanding the least-complicated path to successfully dleivering accessiblity in products with options is what IT folks need. As ar as the bolt-on and bridge language, it is simpler to say how to build-it in, but at the end of the day as long as we provide clear direction on “how” to do it we’ve done our part.