An introduction to ARIA attributes

What is ARIA?

ARIA has become an important aspect of web development but these attributes are still somewhat of a mystery to me (and admittedly, usually an oversight). Unlike the HTML or CSS specifications, the guidelines for ARIA just aren't that memorable.

I decided to go over the basics of ARIA and work out how to apply them to my everyday work.

What does ARIA solve?

ARIA helps to fill the gap between assistive technologies and the DOM—specifically, when the DOM is manipulated by JavaScript.

As JavaScript became used more and more for adding interactivity to web pages, assistive technologies could not understand what was happening to the dynamic content on a page.

By adding this semantic information assistive technologies can determine how to react to content and provide relevant information to the user. ARIA has a W3C Recommendation containing valuable information on how it should be implemented and parsed.

Roles, states and properties

At its core, ARIA is made up of roles, states and properties. Roles dictate the purpose of a block of content, whereas states and properties provide cues on individual elements.

Roles

HTML5 introduced elements such as <header>, <nav>, <footer> and <article> to bring meaning to commonly used design patterns. Assistive technologies can see this markup and determine the role of those elements automatically.

ARIA helps to define these roles manually, as well as more complex roles such as toolbars, dialogs, tabs, forms and search bars. A full list of roles is found in Section 5.3 in the W3C recommendation.

Some HTML5 elements come with ARIA roles baked in—the ARIA role banner is used within <header> to reduce the amount of markup. This means that the two elements below would both be evaluated to have the same role:

<header></header>
<div role="banner"></div>

ARIA sorts roles as one of six categories:

Abstract;
Widget;
Document Structure;
Landmark;
Live Region; and
Window.

States

Assistive technologies are unable to detect state changes of complex DOM elements. By providing the current state of an object, the browser is able to to properly interact with it and determine how it should be used.

A common functionality of forms is to mark something as invalid. ARIA provides the aria-invalid attribute to indicate this state, as well as providing the option to pass a value with the attribute for extra information.

For example, if there is a spelling error, the aria-invalid="spelling" value can be passed to add this additional information for the browser to detect.

Properties

Where states indicate what a current object is doing, properties act like metadata by providing additional information, such as links to other elements.

An example of a property is the aria-haspopup attribute. This tells the browser that the element has a pop-up context menu or sub-level menu. This could be used on a navigation list:

<nav>
  <ul>
    <li><a href="#">About</a></li>
    <li aria-haspopup="true"><a href="#">Services</a><ul>
      <li><a href="#">Reading</a></li>
      <li><a href="#">Writing</a></li>
      <li><a href="#">Administration</a></li>
    </ul></li>
    <li><a href="#">Blog</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>

Note that the attribute has the value of true. The aria-haspop can have a value of either true or false, but each property will have its own set of possible values (which are documented within the W3C recommendation for each property).

Who uses ARIA?

Popular front-end frameworks and design systems are already integrating these techniques into their codebases.

For example, ZURB Foundation 6's pagination component uses ARIA roles and properties, and so does Bootstrap v3's pagination component, and Salesforce's Lightning Design System makes use of them across the different states of its button component.

These additions appear minimal but provide valuable information to those using assistive technologies. It is good to see popular frameworks putting accessibility as a priority.