Understanding ARIA, for Web Accessibility

Without ARIA, autocomplete fields, such as this example from Amazon, are extremely difficult for screen-reader users.

If you research web accessibility, you’re likely to run into ARIA — Accessible Rich Internet Applications. Some will call it the solution to all web accessibility issues. Others will condemn it for causing problems. Both of these descriptions have an element of truth because, like all web technologies, it depends on how you use it.

ARIA is a specification from the Web Accessibility Initiative of the World Wide Web Consortium. It provides a set of HTML attributes that help assistive technology understand the complex interactions common to modern websites.

For sighted users, relationships between elements on a web page are exposed through placement and design. ARIA provides a way to share these relationships to assistive technology, such as screen readers.

ARIA conveys a few key characteristics: roles, states and properties, and relationships.

• Roles tell a user how a page is structured. Headings, banners, search fields, sidebars, the main content — all of these can be conveyed using roles.

• States and properties tell a user what the current condition is for an element. For example, with a button that opens a panel, is that panel currently open, or closed (aria-expanded)? Is a region dynamic, such that the content of that field might be updated without a page refresh (aria-live)?

• Relationships tell a user whether items are related to each other. This can include descriptions, such as instructions for filling in an input (aria-describedby) or information about what the next element will be for the reading order (aria-flowto).

Autosuggest Fields

Consider an autosuggest input field, such as on Google or Amazon. You start typing, and a script in the background finds results similar to what you’re typing and suggests them as options. Those suggestions will be pulled up in a nearby HTML element that sighted users can see and select from.

An autosuggest field is not a default HTML element. If it were, the suggested results would directly associate with the query field. An autosuggest field is, basically, a much richer version of a select dropdown, where you can only narrow the field by the first letters in the options. With an autosuggest search field, the query rules are typically much more complex.

A select element is a default part of HTML. The options are programmatically associated with the input field, and that information is shared directly with assistive technology, like a screen reader.

The autosuggest field, however, is different: It’s always custom created. Without ARIA, there’s no explicit relationship between the results and the input, which makes it extremely difficult for a screen reader user to know that anything is happening. Using ARIA, we can create a relationship between the input field and the suggestions, and you can inform assistive technology that the updated region will contain new information that needs to be reported to the visitor.

With these simple attributes, in other words, you transform a field where a screen reader user has no idea, to something where any user gets the benefit of the automatic suggestions.

For dynamic regions, in particular, ARIA is not just valuable, but critical to the accessibility of a website. When JavaScript is used to refresh just a portion of the screen, assistive technology frequently has no way to know anything has changed. Declaring a region as aria-live notifies assistive technology what areas of the page to monitor for changes.

When used correctly, ARIA can enormously enhance the accessibility of a site. But if it isn’t, it can create entirely new problems.

ARIA Not a Substitute for HTML

A normal input element is labeled like this.

<label for='your-name'>Your Name</label>
<input name='your-name' id='your-name'/>

You could, but should not, do this.

<span id="your-name">Your Name</span>
<input name='your-name' aria-labelledby='your-name' />


Why is this unacceptable? Because ARIA is only supported by assistive technology. But it’s not even necessarily supported by all assistive technology, and it’s not recognized at all by your browser. So if you’re just using your browser without any assistive technology or you’re using older technology that doesn’t support ARIA, this input field is not labeled at all.

What is a good use of ARIA? Following on the basic form input above, a good use is when you need to convey more extensive directions about your field, such as the following.

<label for="your-birthday">Your Birthday</label>
<input id="your-birthday" name="your-birthday" aria-describedby='date-format' type="text" />
<span id="date-format">Enter date in YY/MM/DD format</span>


This is effective because the label itself doesn’t convey all the information necessary to fill out the field. But it is enhanced by a description, which is now explicitly associated with the input field, and will be read to the user by his screen reader after the label.

ARIA Enhances HTML

HTML has a lot of built-in meaning. Form fields have labels, headings lend structure, and images have alternative text. When you’re building an accessible website, your first step is to connect every dot within your HTML. When the semantic meanings already exist in an HTML element, you don’t need to extend it with ARIA. Once you have the HTML refined, add ARIA attributes when you cannot convey the information in HTML.

Don’t Get Carried Away

It’s tempting to explore ARIA attributes and add them everywhere. Do not. ARIA enhances the meaning of HTML elements, but that doesn’t mean that HTML doesn’t already have meaning. If you look at a standard HTML element like <h1>, that element, by itself, is the same as writing <h1 role=’heading’ aria-level=’1’/>. You don’t need to include that role or aria-level attribute — they are redundant.

There’s also no reason to use <h1 role=’heading’ aria-level=’2′>. That code says that the H1 heading has the meaning of an H2. Well, if it means H2, then use an H2. That is much simpler.