ARIA Deep Dive
@INCOMPLETE
Table of Contents
What is ARIA?
ARIA stands for Accessible Rich Internet Applications and is defined by the World Wide Web Consortium. ARIA is used to help users who rely on screen readers understand what’s going on when a custom JavaScript event or script that is fired. Imagine you’re reading content on a website and an alert pops up in a corner of your screen, perhaps to say that a download is complete or that there has been some kind of error. Unless that popup event is tied to an action in ARIA, any user with a screen reader would have no idea that it ever occured, and their reader would keep on reading whatever text they were previously focused on.
One way to think about ARIA is that it is analogous to HTML. The difference between a plain old document of just text and an HTML document is that HTML adds a layer metadata and information that a browser uses to change how the document’s text and other elements are displayed. HTML can also change how things function, like a form or link, but ignore those for a second. HTML doesn’t change the text or what the document says, it just changes what it looks like and how it is laid out.
ARIA is just like that. It adds an additional layer of metadata to the HTML document. Instead of changing how it looks and behaves, it just adds additional information that is useful for screen readers. That’s it. ARIA is ONLY useful for screen readers. It doesn’t change anything about a page visually. For example, the attribute aria-hidden="true" doesn’t visually hide anything, but it does “hide” the element from screen readers.
When Should I Use ARIA?
HTML does the job just fine most of the time. If there is a native HTML element for something you want, like a <header>, <nav>, <section>, or <form>, just use it. ARIA should be used when there is a scripting event or a custom element that requires more than standard HTML to function. In those cases, browsers, screen readers, and other renderers must be able to determine the following properties:
- label (or name)
- role
- state
- value
and must be notified of any changes to these properties.
If you’re going to use ARIA, you must be thorough! Go all in or don’t use it at all. Imagine a user that is reliant on but also very experienced with screen reader technologies. The following situations are in order of preference:
- An ARIA-compliant site. All of the controls work the way they’re supposed to, and interactions are easy and follow expected conventions.
- A site with no ARIA code at all. It’s a pain in the neck to get around, but it’s something that the user is unfortunately kind of used to. Things aren’t easy, but at least all of their keyboard shortcuts don’t break.
- A site that has some ARIA in places, but not all. What a mess! The site behaves in unpredictable ways. Some controls work and some require switching to another set of shortcuts and keystrokes. The experience is extremely frustrating and everything has to be learned one element at a time.
A helpful way to remember this is the ARIA axioms:
- NEVER use ARIA unless you have to.
- ALWAYS use ARIA when you have to.
- You’re probably doing it wrong.
ARIA Labels and Names
When a screen reader comes to an element, what will it say? It depends. “Accessible Names” are computed using the following priorities:
aria-labelledby- If this attribute exists, it will override any other name and label methods.aria-label- Second choice. Note that this text is invisible except to screen readers.- Native Text - The text inside an element’s tags (like in a
<button>) or standard alternatives (<label>on form,alton an image). title- As a last resort, thetitlemay be used. Don’t rely ontitlebecause it generally only shows up when users hover over something, and keyboard and mobile users don’t have a hover mechanism.
aria-labelledby
The aria-labelledby property is a reference or pointer to another element where the current element’s name is. For example, if you had an image on your page with a caption under it that sighted users could read, you can use that caption as your alt text instead of adding it again to the image.
<!-- Bad example: A screen reader would read the alt text twice: once on the image and again right below it. -->
<img src="pollock_painting.png" alt="Jackson Pollock's 'drip technique' is an example of abstract art.">
<div class="citation">Jackson Pollock's 'drip technique' is an example of abstract art.</div>
<!-- Better example: When the screen reader finds the image, it will read the proper citation once. -->
<img src="pollock_painting.png" aria-labelledby="pollock_citation">
<div class="citation" id="pollock_citation">Jackson Pollock's 'drip technique' is an example of abstract art.</div>
<!-- Best example: When a semantic HTML equivalent exists, skip ARIA altogether -->
<figure>
<img src="pollock_painting.png">
<figcaption>Jackson Pollock's 'drip technique' is an example of abstract art.</figcaption>
</figure>
aria-label
The aria-label property is a way to add a label to an element that does not normally appear on screen. Since aria-label is prioritized over native text, screen readers will use this instead of whatever text is already inside the element.
<!-- Screen readers should say 'Close Window' instead of 'X' -->
<button onClick="closeWindow" aria-label="Close Window">X</button>
<!-- This can be used to make links more descriptive, since links are often read in a list and lose some context -->
<a href="http://w3.org" aria-label="The World Wide Web Consortium">W3C</a>