This is the third in a series I’m writing on accessible web experiences. In the first article, “The ADA and Universal Design: Why Do We Develop Accessible Web Experiences?” I discussed the “why” of accessible digital design. In “The ADA and Universal Design: Building a Better Blueprint,” I discussed how to create personas, user journeys, sitemaps, and wireframes consistent with the principles of universal design. In this article, I’ll discuss techniques for making web experiences accessible for screen readers and other assistive devices.

Imagine this experience: You go to a website to search for critical information you need to do your job. Or to order a refill of an important prescription. Or to download the new album that your favorite band just dropped.

You navigate to the site, but you have to hunt for five minutes before you find the search bar. (It was buried down at the very bottom of the footer, underneath the copyright notice.) You find your way to a form that is labeled “form.” The form has a text field that’s labeled “generic” and prompts you to enter “text field.” Down at the bottom, there’s a button labeled “button.” While you’re trying to figure it all out, the page times out, and you have to start all over. (A countdown alert popped up to warn you, but you didn’t notice it.)

How’s your experience going so far? Finding what you need? Feeling like your time is well spent? Or are you getting ready to abandon the site and try somewhere else?

This is analogous to the experience of someone accessing a website with a screen reader or other assistive technology when the site hasn’t been developed according to the best practices of accessible website design.

ARIA to the Rescue

To address this growing problem, W3C created the Web Accessibility Initiative—Accessible Rich Internet Applications (WAI-ARIA, or simply ARIA). ARIA is a framework of attributes you can add to HTML elements, providing added context and alternative, text-based information. ARIA attributes make web applications more accessible to people who use screen readers, braille displays, keyboard-only navigation, and other assistive technologies.

Note that ARIA attributes only make web experiences better for those who use assistive technologies. It has been my premise in this series that accessible web design makes websites better for everyone, not only for people with disabilities. I think that’s true even here, because ARIA forces us to take a hard look at the organization and interactions of our web experiences.

As I’ll cover in my first best practice, the best solution is not to create a separate experience for users with disabilities. If you’re using ARIA to substantially alter your web experience, I urge you instead to rethink the experience you’re creating for all. Many ARIA fixes will then become unnecessary… and your websites will be better for everyone.

Best Practices for ARIA

#1: Start With Semantic HTML

Don’t throw good ARIA at bad HTML. When you develop sites using well-formed semantic HTML, you won’t need to rely heavily on ARIA attributes to make them accessible.

If your web app uses a

element as a button, an ARIA role can inform screen readers that it’s a button:

Order Milkshake

But why not use semantic HTML instead?

It’s more adaptable, more machine readable, and may even enhance your SEO.

There are some scenarios in which you can’t use semantic HTML:

It’s someone else’s code, and you don’t have the authority to change it.
It’s legacy code, and you don’t have the budget to fix it.
Required displays and devices don’t support the semantic element.
HTML5 doesn’t specify the semantic element you need.

In these cases, you have no choice but to fix generic elements with ARIA attributes. But whenever you have a choice, use semantic HTML instead.

#2: Design a Better DOM

You may already know how a well structured Document Object Model (DOM) can enhance SEO. This comes up most often when JavaScript manipulates the DOM, sometimes in ways that search engines struggle to crawl. But even some rudimentary SEO practices are fundamentally about the DOM.

When you string together a bunch of

and elements, search engines and assistive technologies have no structure to guide them. They see only a collection of generic content.

Instead, organize your content logically in

,

–

, and other semantic elements. Make the structure of the document much more explicit and easier for assistive technologies to navigate. (Search engine spiders will thank you too.)

#3: Trim the Accessibility Tree

A web document’s accessibility tree is a transformation of the DOM, rendered by the browser and made available to assistive technology. It is both less and more than the DOM. Browsers remove extraneous information and add additional (sometimes computed) information to help people using assistive technologies.

Inspect your web app’s accessibility tree to see what information will be sent to assistive technologies. What important information is missing? What extraneous information is included? What generic information could be made more precise?

Make a list, then go back to best practices #1 and #2. Can you add the missing information to the DOM? Should that extraneous information be in your web app? Can you use more informative semantic HTML?

If you can fix the accessibility tree with the above techniques, do so. It will make for a clearer document structure and cleaner code. Search engines and assistive technologies will both understand it better.

But there will be times when you can’t fix the accessibility tree in these ways. In this case, it’s time to use a little ARIA.

#4: Lightly Apply ARIA Landmarks and Other Roles

We looked briefly at ARIA roles in the example in #1. I urged you to use semantic HTML instead.

However, HTML5 does not specify all the semantic elements you might need to build your web app. Even where it does, some elements aren’t supported across all displays and devices. These elements include common features of modern web experiences such as dropdown and hamburger menus, pop-ups, and alerts.

ARIA roles close the accessibility gap by explicitly defining the semantic role of an element. ARIA landmarks are a subset of roles that define the main content areas of a document, such as a navigation menu or search tool.

Alerts, for example, convey time-sensitive information that a user should read immediately. However, there is no element in HTML to convey this urgency to assistive technologies. Here’s where an ARIA role steps in.

The CSV number is required to complete your order.

With the “alert” role set, screen readers will immediately announce the alert and read the text within it.

#5: Fill in the Final Gaps with ARIA States and Properties

Finally, we have ARIA states and properties. These ARIA attributes do have a place in accessible web experiences, but you should use them only after getting the most out of practices 1-4.

At my agency, more than 90% of our ARIA attribute usage comes down to the roles and landmarks in #4 and three ARIA properties:

aria-label to describe elements with no visible text label, such as hamburger menus
aria-labeledby to identify another element whose text labels the element
aria-describedby to identify another element that has additional information about the element

Conclusion

When creating accessible web experiences, knowing when not to use ARIA labels is just as important as knowing when you should. Use the lens of ARIA to examine your web apps more deeply. Make them as accessible as you can without adding ARIA, then use ARIA roles, properties, and states to get you the rest of the way there. You’ll end up with a rich Internet application that works better for everyone.