W3C definition of WAI-ARIA
“WAI-ARIA provides a framework for adding attributes to identify features for user interaction, how they relate to each other, and their current state.”
Some elements of the framework can be used on their own to add accessibility to web content (e.g., landmarks). More often, they are combined with scripting that is used to dynamically add or remove WAI-ARIA attributes depending on the context.
WAI-ARIA provides semantics for custom widgets and web applications that can be understood by assistive technologies (ATs) and conveyed to users in a “human understandable” form. For example, HTML list markup might be used to create a navigation bar with menus and submenus. Without WAI-ARIA a screen reader would simply recognize the navigation bar as a collection of nested lists. Adding WAI-ARIA menu attributes (e.g., menubar, menu, menuitem, aria-haspopup, aria-expanded) can give the nested list a whole new meaning, more easily understood as a means of navigation than the list would be understood.
W3C definition of semantics
“The meaning of something as understood by a human, defined in a way that computers can process a representation of an object, such as elements and attributes, and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.”
This definition of semantics in programming is much like the common definition of the word: “the meaning, or an interpretation of the meaning” (dictionary.com). Semantics in the context of web accessibility refers to the defining of meaning as it applies to functional elements of web content, and how that functionality is conveyed to assistive technology users, especially, screen reader users.
When and When Not to Use WAI-ARIA
WAI-ARIA is supposed to be used when semantics are required to make a web application or widget understandable. For example, if you are using a
<div> to create a checkbox, along with some scripting you can assign the WAI-ARIA role “checkbox” to that
<div> to make it appear as a checkbox.
That said though, when there is a native HTML element available, like a checkbox, it is almost always better to use the native version than creating your own. The native version will already have all the associated semantics by default. Since the native versions are standardized, they are more likely to be supported across browsers and assistive technologies.
For native HTML elements, it is not necessary to use WAI-ARIA. For an HTML
<form> element for instance, there is no need to include
role="form" with the element. There are a few exceptions to this rule, however. For some of the newer HTML5 elements, like
<main> for instance, it does not hurt to include the WAI-ARIA equivalent
role="main" in these elements for the time being, to accommodate some of the inconsistent support for these elements across browsers and ATs. HTML validators will still give you warnings about the redundant roles, but you can safely ignore these.
You should also be careful when using WAI-ARIA with HTML elements that already have semantics. For example, if you use
<h3 role="button">something</h3>, the semantics associated with the heading will be overridden, thus, potentially breaking the structure of a document. In a case like this, a better approach would be to wrap the heading in a
<div> then assign
role="button" to the
<div> to preserve the structural semantics of the heading, as seen in the examples below.