Aria Grande: a light introduction to ARIA for designers
As designers, ignorance can often lead to poor execution. If we don’t have a basic concept of how to create accessible websites it will be hard to advocate for them in the real workplace. As designers we also have a responsibility to define how it works. This includes how it works for all people.
When I first heard about ARIA, I just started throwing aria-hidden="true" on a bunch of elements without really knowing why, all the while espousing the virtues of “accessibility.” But ARIA is meant for so much more than simply hiding elements and it’s significantly more complicated that it at first might appear. To challenge my ignorance, I spent sometime digging into the basics of ARIA. What is it actually, how do we use it, and when is it even appropriate? Hopefully these learnings may be of benefit to others looking get off the peak of mt stupid.
The first rule of ARIA is to never use ARIA
HTML just works. Accessibility tools have been built to understand most every piece of content and variety of input. By default, most webpages should be accessible out-of-the-box without much additional work by either designer or developer.
And this is where we can get into trouble with ARIA. It’s a tool that extends and manipulates the way accessibility tools understand the core HTML. Utilizing ARIA can be a little like taking apart an engine and not knowing how to put the thing back together again. You’re worse off than when you started, and your project can actually become less accessible. The MDN docs go so far as to state, “No ARIA is better than bad ARIA.”
Long story short, ARIA is not a substitute for writing quality, semantic HTML. By sticking to and practicing the fundamentals of good HTML we avoid creating most accessibility problems. Full stop. And except for the fact that we haven’t actually learned anything about ARIA, this article could honestly end here.
Semantic HTML — it is what it is
Semantic HTML, in a nutshell, is just calling a thing what it is. An HTML tag should accurately reflect the content it contains: Lists goes in <ul> or <ol> tags, images go in <img>, paragraphs go in <p>, etc.
This sounds simple at first but it takes diligence to follow through on. There are many ways to cut corners when writing HTML. As an example—you’re developing an Ariana Grande fan website:
Your site has a fluid layout and the exact dimensions of featured images are based on screen size. It’s super easy to use background:cover to handle such instances. It’s a quick and easy method to get an image on a page. So you add <div class= "article-cover" style="background: url("ariana-pete.jpg") cover;"></div> to your fan site. This is a bad move, you’ve hidden the image from the HTML structure of the page and instead added an empty div… And as there’s no alt attribute for background images, screen readers will pass right over this image making the image completely inaccessible.
The appropriate solution is a regular ol’ image tag: <img src="ariana-pete.jpg" alt="Ariana Grande and Pete Davidson at the VMAs">. To handle the responsive behavior one can make use of the object-fit property. So now you’re using an image element for an image 🎉. In this way, you’ve told the browser that there’s an image here and allowed the image to be accessible to screen readers.
Elements > class names
While the above example might be more egregious, more subtle mistakes include not using or improperly using HTML5 elements to define layouts. Instead of <div class="navigation">…</div>, one should use <nav>…</nav>. This tells both the browser (and therefore screen readers) where the navigation on the page is and makes navigating a webpage by screenreader remarkably easier.
There is a lot one could say on writing semantic HTML but this is an article about ARIA… for designers who may or may not care about semantics. But if you’re unfamiliar with the concept, I’d highly recommend spending just a little time familiarizing yourself with it. I’d also encourage spending time reading some HTML5 documentation.
For real. What even is ARIA?
Using semantic HTML properly will cover most screen reader use cases out-of-the box. But inevitably a there will come a time when you hit a technical limitation or you design something a little too crazy and basic HTML5 won’t cut it. ARIA (Accessible Rich Internet Applications) supplements HTML with attributes that defines otherwise inaccessible interactions, states, and relationships. By simply adding an attribute to an HTML element we can dramatically improve its accessibility.
ARIA attributes are traditionally defined in 3 separate categories: Roles, properties and states. They look a little something like this:
ROLES
<div class="option" role="checkbox" aria-checked="true">…</div>PROPERTIES
<image src="annual-data.svg" aria-describedby="#annual-intro">STATES
<div class="option" role="checkbox" aria-checked="true">…</div>
ARIA Roles
An ARIA role basically tells accessibility tools what an element is and how they can engage with it. For example, the humble div tags has no semantic meaning, it doesn’t provide any context to accessibility tools. A div tag can literally contain anything. So if you need to use a div as button to power some javascript function, you could add the aria attribute role=”button” to the tag. This will tell screen readers (and other tools) that the element is an interactive button.
Roles are broken down into 3 subcategories
- Widgets — These are traditionally used to define more complex (usually javascript powered) interfaces. This list includes items such as buttons, links, textboxes, radios, progressbar, timers, tooltips and many many others.
- Document—Document roles are used to provide structure to the html document. These allow you to define articles, images, rows, etc. This provides helpful context for screen readers as they progress through the document.
- Landmark—Similar to the document role, the landmark category defines important regions screen readers and keyboards can jump to quickly. This includes the likes of navigation, forms and search.
ARIA Properties
ARIA properties are used to describe elements in context. For example, an Ariana Grande knowledge quiz might have a slider widget allowing visitors to guess Ariana’s height. You can use aria-valuemin="90" and aria-valuemax="200" to provide information about the possible range of the slider.
ARIA States
As defined in the Material Design documentation: “States are visual representations used to communicate the status of a component or interactive element.” ARIA states are essentially the same thing, but don’t require a visual (read inaccessible) representation. We could reword Material’s definition this way, “States are textual representations used to communicate the status of a component or interactive element.”
As an example, if you’re building a custom checkbox, it’s important to let screen readers know the state of each box. Likely with the aid of some javascript you’d add aria-checked="true" or aria-checked=false to the checkbox to pass along the state to a screen reader.
*A full list of roles, properties and states can be found on Mozilla.
Poorly brainstormed example time!
Basics terminology out of the way, let’s pretend you have a site dedicated to music and make money from ad revenue. You suspect you’ll be able to increase your ad revenue with a poorly designed click-bait personality quiz. One of the questions in your quiz has users pick their favorite Ariana Grande album:
This selection question, functionally, behaves the same as a standard radio input. Each album cover is a custom radio input within a radio group. In traditional HTML, each album would look something like this <input type="radio" id="positions" name="album" value="positions" checked>
Unfortunately, in this example, the cheap CMS you built your site on doesn’t allow you to feasibly customize inputs to the level required for this design… All the styling and images would be exceedingly difficult to develop. So instead of using inputs you decide to rely heavily on javascript. For each album we could do something more custom:
<div class="albums" role="radiogroup" aria-labelledby="album-heading">
<h3 id="album-heading">Select your favorite album</h3>
<div class="cover selected" role="radio" aria-checked="true" tabindex="0"><img src="positions.png" alt="Positions"></div>
<div class="cover" role="radio" aria-checked="false" tabindex="-1"><img src="thank-u-next.png" alt="thank u, next"></div>
<div class="cover" role="radio" aria-checked="false" tabindex="-1"><img src="sweetener.png" alt="Sweetener"></div>
</div>Instead of nested divs, we’ve declared to accessibility tools that here we have a radio group with three radio inputs. Each option is defined as an individual radio input with its state defined as true or false. And finally to handle the basics of keyboard accessibility we’ve added tab index.
All of this would, of course, require javascript to power the pseudo-form. Additional javascript is needed to change the aria properties based on user selection. And THEN you’d need to ensure inputs can be properly selected by keyboard with even more javascript. This example should also make clear that using base HTML is not only preferred for accessibility standards, it’s also just way easier to create.
For an in-depth (and honestly far better, more accurate) example of ARIA in action, take a look at Léonie Watson’s ARIA, Accessibility APIs and coding like you give a damn!
How does this apply to designers?
You might be asking yourself, “Ariana Grande is a great singer, but how does this stuff about HTML code apply to me a designer?” Good question. It’s most frequently developers who are ultimately responsible for building accessibility into websites. Larger organizations may even have dedicated accessibility developers. For most designers, this information probably provides helpful context but is not immediately applicable.
However, we designers often like to stretch what’s possible and push boundaries in the pursuit of a novel and useful design. Some of the more unique interactions we create may not be accessible solely using semantic HTML. It is in these instances where we need to be sure we’re accounting for accessibility and working with our developer friends to ensure everyone can use the thing you’re making. Below are some common instances of html falling short:
Tablists
A common space saving method in design is the use of tabs. It’s a way to organize content in an efficient manner allowing users to choose the content they want to engage with. No HTML element exists to define tabs but we can use the ARIA tablist, tab and tab panel roles to aid with accessibility here. More info in the MDN documentaion.
Drag and drop
Drag-and-drop functionality can used in a number of ways but a common pattern is to move items from one list to another, often used in pipeline/task management software such as Asana. They can also be used to resize columns in a table, or sort a list. Because the uses of drag-and-drop functionality vary so dramatically, there’s no one size fits all ARIA solution but aria-grabbed and aria-dropeffect can be used to define a draggable element and where that element can be placed. Check out Jesse Hausler’s article for a good break down of drag-and-drop accessibility.
Dropdowns
Dropdowns allow users to select an option from a typically long list of options. Unlike other options from this list there is an HTML equivalent for dropdowns: <select>. However, the select box is notoriously difficult to style… many developers choose to create something custom rather than deal with the select box challenges.
To the unfamiliar, drop-downs are surprisingly complicated little pieces of UI. You need controls to open the dropdown, output the list within the dropdown, select an element (or multiple elements) within that list, show the user what element is selected, and close the dropdown. The list of aria properties associated with this UI pattern is appropriately lengthy: aria-labelledby, aria-haspopup, aria-expanded, aria-labelledby,tabindex, aria-activedescendant and aria-selected. Checkout W3C’s example for a break down of these properties
Accordions/toggles
There may be an argument that accordions follow the same pattern as the tablist mentioned above. They both reveal content associated with label/header. But the W3C example makes use of the aria-expanded, aria-controlsand aria-labelledby attributes and would be the example to follow.
Dialogs
Sometimes called a modal this is the dreaded pop up. Love ‘em or hate ‘em they are a reality. When a modal appears focus should transition to the dialog and shouldn’t ever leave the dialog box. We can use role="dialog" to define a dialog and lock the focus to the proper location. The W3C documentation outlines the use of dialogs and provides an excellent example.
Note on ARIA hidden
As mentioned in the introduction, I have previously abused this feature and thus, feel it’s worth a special note. Adding aria-hidden="true" to an element to will ensure it and it’s contents won’t be read by screen readers.
One of the most common uses I have personally seen (and used) for this attribute is to hide decorative images: <img src="ariana.jpg" aria-hidden="true"> But this is often inappropriate considering the first rule of ARIA (which is to not use ARIA) and most standards/validators call for all images to have an alt tag. If an image is truly decorative, an empty alt tag is the best solution: <img src="ariana.jpg" alt="">
In practice, I’ve found that designers are responsible for imagery and are therefore most suited to determine whether or not an image is decorative but that may be different in your organization. Shameless plug, check out this article on writing good alt text.
However, there are times when aria-hidden is definitely useful. One particular use case would for the ubiquitous Font Awesome icon library. Instead of images, Font Awesome uses the <i> tag to declare iconography (against semantic html btw) and in HTML looks something like this:
<a href="path/to/shopping/cart" aria-label="View 3 items in your shopping cart">
<i class="fa fa-shopping-cart" aria-hidden="true"></i>
</a>Because the <i> element doesn’t accept alt attributes, you’ll need to make use of ARIA to ensure elements are accessible for both screen readers and sighted users. In their own documentation, they recommend using aria-hidden="true" on all icons and adding aria-title="…" or aria-label="…" depending on the context of the icon in question.
Further reading
I’ll end this article with some resources. I’m most assuredly not an expert on ARIA (please let me know if this article contains wrong information) so if you wish to learn more on the subject check out these sites:
