Introduction to ARIA and non-native HTML semantics
Dave Gash
Meggin Kearney
So far, we've encouraged using native HTML elements because they give you focus,keyboard support, and built-in semantics, but there are times when a simplelayout and native HTML won't do the job. For example, currently there's nostandardized HTML element for a very common UI construct, the pop-up menu. Noris there an HTML element that provides a semantic characteristic such as "theuser needs to know about this as soon as possible".
In this lesson, then, we'll explore how to express semantics that HTML can'texpress on its own.
The Web Accessibility Initiative's Accessible Rich Internet Applicationsspecification (WAI-ARIA, or justARIA) is good for bridging areas with accessibility issues that can't be managedwith native HTML. It works by allowing you to specify attributes that modify theway an element is translated into the accessibility tree. Let's look at anexample.
In the following snippet, we use a list item as a kind of custom checkbox. TheCSS "checkbox" class gives the element the required visual characteristics.
<li tabindex="0" class="checkbox" checked> Receive promotional offers</li>While this works fine for sighted users, a screen reader will give no indicationthat the element is meant to be a checkbox, so low-vision users may miss theelement entirely.
Using ARIA attributes, however, we can give the element the missing informationso the screen reader can properly interpret it. Here, we've added the role andaria-checked attributes to explicitly identify the element as a checkbox andto specify that it is checked by default. The list item will now be added to theaccessibility tree and a screen reader will correctly report it as a checkbox.
<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true"> Receive promotional offers</li>ARIA works by changing and augmenting the standard DOM accessibility tree.
Although ARIA allows us to subtly (or even radically) modify the accessibilitytree for any element on the page, that is the only thing it changes. ARIAdoesn't augment any of the element's inherent behavior; it won't make theelement focusable or give it keyboard event listeners. That is still part of ourdevelopment task.
It's important to understand that there is no need to redefine defaultsemantics. Regardless of its use, a standard HTML <input type="checkbox">element doesn't need an additional role="checkbox" ARIA attribute to becorrectly announced.
It's also worth noting that certain HTML elements have restrictions on what ARIAroles and attributes can be used on them. For example, a standard <inputtype="text"> element may not have any additional role/attribute applied to it.
See the ARIA in HTML specfor more information.
Let's see what other capabilities ARIA has to offer.
What can ARIA do?
As you saw with the checkbox example, ARIA can modify existing element semanticsor add semantics to elements where no native semantics exist. It can alsoexpress semantic patterns that don't exist at all in HTML, like a menu or a tabpanel. Often, ARIA lets us create widget-type elements that wouldn't be possiblewith plain HTML.
- For example, ARIA can add extra label and description text that is onlyexposed to assistive technology APIs.
<button aria-label="screen reader only label"></button>- ARIA can express semantic relationships between elements that extend thestandard parent/child connection, such as a custom scrollbar that controls aspecific region.
<div role="scrollbar" aria-controls="main"></div> <div id="main"> . . . </div>- And ARIA can make parts of the page "live," so they immediately informassistive technology when they change.
<div aria-live="polite"> <span>GOOG: $400</span> </div>One of the core aspects of the ARIA system is its collection of roles. A rolein accessibility terms amounts to a shorthand indicator for a particular UIpattern. ARIA provides a vocabulary of patterns we can use via the roleattribute on any HTML element.
When we applied role="checkbox" in the previous example, we were tellingassistive technology that the element should follow the "checkbox" pattern. Thatis, we're guaranteeing that it will have a checked state (either checked or notchecked), and that the state may be toggled using the mouse or the spacebar,just like a standard HTML checkbox element.
In fact, because keyboard interactions feature so prominently in screen readerusage, it's very important to make sure that, when creating a custom widget, therole attribute is always applied in the same place as the tabindexattribute; this ensures that keyboard events go to the right place and that whenfocus lands on an element its role is conveyed accurately.
The ARIA spec describes ataxonomy of possible values for the role attribute and associated ARIAattributes that may be used in conjunction with those roles. This is the bestsource of definitive information about how the ARIA roles and attributes worktogether and how they can be used in a way that is supported by browsers andassistive technologies.
However, the spec is very dense; a more approachable place to start is the ARIAAuthoring Practices document, which explores best practices for using the available ARIA roles andproperties.
ARIA also offers landmark roles that extend the options available in HTML5. Seethe Landmark Roles DesignPatternsspec for more information.
