There is a lot of confusion around the integration of HTML5 and WAI-ARIA, even amongst professionals in the field who have been working with the technologies for some time. One reason for the confusion, at least for me, is that WAI-ARIA defines a set of rules for mapping roles, states and properties to an accessibility API, and does not define any functionality other than this; whereas, HTML5 defines functionality, often but not always relying on WAI-ARIA for accessibility API mapping. This article seeks to answer common questions about the use of WAI-ARIA in HTML5.

Definitions

HTML5

This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.

WAI-ARIA

This specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup.

What HTML5 says about WAI-ARIA

Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below. These exceptions are intended to prevent authors from making assistive technology products report nonsensical states that do not represent the actual state of the document.

User agents are required to implement ARIA semantics on all HTML elements, as defined in the ARIA specifications. The implicit ARIA semantics defined below must be recognized by implementations for the purposes of ARIA processing.

The ARIA attributes defined in the ARIA specifications, and the strong native semantics and default implicit ARIA semantics defined below, do not have any effect on CSS pseudo-class matching, user interface modalities that don't use assistive technologies, or the default actions of user interaction events as described in this specification. ( http://dev.w3.org/html5/spec/wai-aria.html )

What WAI-ARIA says about Implementation

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 host language provides a semantic element for that type of objects. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it's better to use an h1 element in HTML than to use the heading role on a div element.

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can 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 and accessible 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. ( http://www.w3.org/TR/wai-aria/introduction#co-evolution )

Confusions

I, and others I know, have been confused about the implementation of WAI-ARIA in HTML5. Below are some issues that have arisen, and some explanations, that should help to make things more clear in the future. I believe that for myself the confusion has come from:

1. Wishing that WAI-ARIA could do more than map semantics to accessibility APIs.
2. Wishing that HTML5 did not implement WAI-ARIA at all, but that it was indeed a fully accessible specification without the use of WAI-ARIA.

HTML5 required and WAI-ARIA aria-required

Back in June @SteveFaulkner opened a bug against Firefox, regarding required and aria-required. Steve had noticed that there were differences in how input elements were treated by Firefox, depending on if they had the HTML5 required attribute set, or the aria-required attribute set.

This confused me as well, in essence these two attributes say the same thing, that the input field is required. The difference is that while both attributes signal to assistive technology, through an accessibility API, that a field is required, only the HTML5 required attributed "does" anything.

The HTML5 required attribute tells user agents (browsers) that a field must have a value set in order to validate, in order for the form to submit. aria-required simply tells an accessibility API that an element's value is required. This places a burden on user agents to ensure that they are exposing any validation messages, when a user attempts to submit a form that has missing values in required fields, in a manner that is accessible to all users.

HTML5 draggable and WAI-ARIA aria-grabbed

I have read through the HTML5 Drag and Drop API several times to ensure that the API contains everything necessary for user agents to implement drag and drop operations that are accessible to all. In so doing the most confusing issue that I have come across is the need for user agents to be able to enumerate a list of draggable elements, and dropzones for the elements being dragged.

The HTML5 draggable attribute can be applied to any element to indicate to user agents that activating the element should commence a drag operation. The API does not define how the element is to be activated, leaving this to user agents to implement. Once a draggable element has been activated user agents must fire a dragStart event at the element.

The WAI-ARIA aria-grabbed attribute is used in much the same way. If aria-grabbed is applied to an element it indicates to assistive technology, through an accessibility API, that the element is available to be grabbed, to commence a drag operation. It does not tell a user agent to use the element to start a drag operation, and the element to which it is applied does not have a dragStart event fired at it when activated.

It would seem, at first glance, that aria-grabbed is made redundant by the HTML5 draggable attribute, or at least this is what I first thought. HTML5, however, also declares that all <a> and <img> elements have their draggable attribute set by default. This means that if an author defines one draggable element on a page, which happens to have 30 images and 30 links, that the enumerated list of draggable elements would be 61. This, in some situations, may not cause any problem at all. It may, however, cause a serious problem for discoverability, and ease of use, depending on how user agents implement drag and drop operations for keyboard only users. In this case, if aria-grabbed is used on the one element that authors intend to be the starting point of the drag operation, user agents that enumerate elements with aria-grabbed set may provide far more valuable information to assistive technology than those that enumerate all draggable elements.

HTML5 a and img; and WAI-ARIA link and img roles

As mentioned above, the HTML5 Drag and Drop API specifies that all <a> and <img> elements should have their draggable attribute set by default. @JohnFoliot opened an HTML5 bug requesting that draggable be applied to elements with their WAI-ARIA role set to "link" or "img" as well. Functionally these are equivalents to the elements <a> and <img>, which they represent. Well, they are functionally equivalent, and they are not, and they are.

If the function is to inform assistive technology, through an accessibility API, that the element has the role of a link or image, than <a> is equivalent to <div role="link">.

If the function is to have something link-like happen (like switching to a different page), then there is no functional equivalence, as role="link" and role="img" have only one function, to inform assistive technology that the element to which they are applied should be recognized as a link, or image, respectively.

Since there is absolutely no reason to set role="link" on an element that is not going to perform link-like behavior, the same being true for role="img", then in a properly authored document the WAI-ARIA roles are functionally equivalent to their HTML5 counterpart elements.

Conclusion

From the above examples what can we conclude. Firstly, the primary, if not sole, purpose of WAI-ARIA is to provide information about elements in an document to assistive technology, through an accessibility API. Secondly, HTML5 on its own, without the use of WAI-ARIA is not sufficient for ensuring a fully accessible experience to users. Finally, There are situations where the line is blurred between HTML5 and WAI-ARIA, where the functionality of attributes are almost the same, but differ enough to be confusing, and to have an impact on how the two technologies must be implemented by user agents, including assistive technology.