Much like their physical counterparts, the materials we use to build websites have purpose. To use them without understanding their strengths and limitations is irresponsible. Nobody wants to live in an poorly-built house. So why are poorly-built websites acceptable?
In this post, I’m going to address WAI-ARIA, and how misusing it can do more harm than good.
Materials as technology
In construction, spackle is used to fix minor defects on interiors. It is a thick paste that dries into a solid surface that can be sanded smooth and painted over. Most renters become acquainted with it when attempting to get their damage deposit back.
Rebar is a lattice of steel rods used to reinforce concrete. Every modern building uses it—chances are good you’ll see it walking past any decent-sized construction site.
Technology as materials
Every tag in HTML has what is known as native semantics. The act of writing an HTML element programmatically communicates to the browser what that tag represents. Writing a
button tag explicitly tells the browser, “This is a button. It does buttony things.”
The reason this is so important is that assistive technology hooks into native semantics and uses it to create an interface for navigation. A page not described semantically is a lot like a building without rooms or windows: People navigating via a screen reader have to wander around aimlessly in the dark and hope they stumble onto what they need.
Using spackle to build walls
A concerning trend I’ve seen recently is the blind, mass-application of ARIA. It feels like an attempt by developers to conduct accessibility compliance via buckshot—throw enough of something at a target trusting that you’ll eventually hit it.
Unfortunately, there is a very real danger to this approach. Misapplied ARIA has the potential to do more harm than good.
The semantics inherent in ARIA means that when applied improperly it can create a discordant, contradictory mess when read via screen reader. Instead of hearing, “This is a button. It does buttony things.”, people begin to hear things along the lines of, “This is nothing, but also a button. But it’s also a deactivated checkbox that is disabled and it needs to shout that constantly.”
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
– First rule of ARIA use
In addition, ARIA is a new technology. This means that browser support and behavior is varied. While I am optimistic that in the future the major browsers will have complete and unified support, the current landscape has gaps and bugs.
Another important consideration is who actually uses the technology. Compliance isn’t some purely academic vanity metric we’re striving for. We’re building robust systems for real people that allow them to get what they want or need with as little complication as possible. Many people who use assistive technology are reluctant to upgrade for fear of breaking functionality. Ever get irritated when your favorite program redesigns and you have to re-learn how to use it? Yeah.
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
– Tim Berners-Lee
This isn’t to say we should completely avoid using ARIA. When applied with skill and precision, it can turn a confusing or frustrating user experience into an intuitive and effortless one, with far fewer brittle hacks and workarounds.
Development teams will appreciate the advantage of terse code that’s easier to maintain. Savvy developers will use a CSS-Trick™ and leverage CSS attribute selectors to create systems where visual presentation is tied to semantic meaning.
border: 4px dotted #f64100;
Here are a few of the more common patterns I’ve seen recently, and why they are problematic. This doesn’t mean these are the only kinds of errors that exist, but it’s a good primer on recognizing what not to do:
<li role="listitem">Hold the Bluetooth button on the speaker for three seconds to make the speaker discoverable</li>
The role is redundant. The native semantics of the
li element already describe it as a list item.
<p role="command">Type CTRL+P to print</p>
command is an Abstract Role. They are only used in ARIA to help describe its taxonomy. Just because an ARIA attribute seems like it is applicable doesn’t mean it necessarily is. Additionally, the
kbd tag could be used on “CTRL” and “P” to more accurately describe the keyboard command.
<div role="button" class="button">Link to device specifications</div>
Failing to use a
button tag runs the risk of not accommodating all the different ways a user can interact with a button and how the browser responds. In addition, the
a tag should be used for links.
<body aria-live="assertive" aria-atomic="true">
Usually the intent behind something like this is to expose updates to the screen reader user. Unfortunately, when scoped to the body tag, any page change—including all JS-related updates—are announced immediately. A setting of
aria-live also means that each update interrupts whatever it is the user is currently doing. This is a disastrous experience, especially for single page apps.
You can style a native checkbox element to look like whatever you want it to. Better support! Less work!
<div role="link" tabindex="40">
Yes, it’s actual production code. Where to begin? First, never use a
tabindex value greater than 0. Secondly, the title attribute probably does not do what you think it does. Third, the anchor tag should have a destination—links take you places, after all. Fourth, the role of
link assigned to a
div wrapping an
a element is entirely superfluous.
<h2 class="h3" role="heading" aria-level="1">How to make a perfect soufflé every time</h2>
Credit is where credit’s due: Nicolas Steenhout outlines the issues for this one.
Much like content, markup shouldn’t be an afterthought when building a website. I believe most people are genuinely trying to do their best most of the time, but wielding a technology without knowing its implications is dangerous and irresponsible.
I’m usually more of a honey-instead-of-vinegar kind of person when I try to get people to practice accessibility, but not here. This isn’t a soft sell about the benefits of developing and designing with an accessible, inclusive mindset. It’s a post about doing your job.
Every decision a team makes affects a site’s accessibility.
– Laura Kalbag
Get better at authoring
Get better at testing
There’s little excuse to not incorporate a screen reader into your testing and QA process. NVDA is free. macOS, Windows, iOS and Android all come with screen readers built in. Some nice people have even written guides to help you learn how to use them.
Automated accessibility testing is a huge boon, but it also isn’t a silver bullet. It won’t report on what it doesn’t know to report, meaning it’s up to a human to manually determine if navigating through the website makes sense. This isn’t any different than other usability testing endeavors.
Build better buildings
- A Book Apart: Accessibility for Everyone, by Laura Kalbag
- egghead.io: Intro to ARIA and Start Building Accessible Web Applications Today, by Marcy Sutton
- Google Developers: Introduction to ARIA, by Meggin Kearney, Dave Gash, and Alice Boxhall
- YouTube: A11ycasts with Rob Dodson, by Rob Dodson
- W3C: WAI-ARIA Authoring Practices 1.1
- W3C: Using ARIA
- Zomigi: Videos of screen readers using ARIA
- Inclusive Components, by Heydon Pickering
- HTML5 Accessibility
- The American Foundation for the Blind: Improving Your Website’s Accessibility
- Designing for All: 5 Ways to Make Your Next Website Design More Accessible, by Carie Fisher
- Accessible Interface Design, by Nick Babich