Let’s talk about W A I (hyphen) A R I A, or Web Accessibility Initiative (hyphen) Accessible Rich Internet Applications for long.
What is ARIA really? And how exactly does it make you rich?
In WebAim’s survey of 1 million home pages, they found that pages including ARIA—a technology designed specifically to make web pages more accessible—actually had 11.2000 more accessibility errors on average than without. Understandably, this prompted a great many people to pick up their pitchforks and begin chanting:
Director’s note: Decimal places
I don't know why I find adding unneeded decimal places so funny but I do.
“DIE, ARIA!”
Is ARIA bad for accessibility? No, it’s v good, but only if you use it correctly. That’s what this video is all about.
To understand ARIA, you first have to understand semantic HTML (or “hootmal”). The difference between a semantic HTML element and an unsemantic one is that the semantic one has meaning that can be read and acted upon by a machine, such as this one first programmed by A WOMAN.
For example, a computer that encounters an <h1> element knows it represents a “first-level heading” and should have an appropriately large, bold font style.
Semantic HTML isn’t just for adding user agent styles you never fucking wanted in the first place and will no doubt override with your own CSS (or “s ssss”). Because web pages aren’t just typeset text, like the book Harry Potter and the Pensioner of Azkaban by Robert Galbraith is just typeset text. They are structures that we navigate, and interfaces that we activate.
Director’s note: JK Rowling
I love how the podcast Comedy Bang Bang’s host always prefixes Rowling’s name with “notorious TERF” whenever she is mentioned. And I love reminding people that JK Rowling is her dead name, since she decided to be called Robert Galbraith.
One way of making this navigation and activation accessible is to make these things compatible with tools like screen readers. Where the HTML is just text and unsemantic elements, that’s all the screen reader gets. With a careful use of semantic HTML, the screen reader can identify important parts of the interface and provide shortcuts between them.
It’s all about cues. Not this kind (pool cue). And definitely not this kind (QAnon). It’s about converting visual cues into non-visual ones.
But if we have semantic HTML already, why do we need ARIA? Or, to put it another way, “WAI?”
In brief, ARIA is another way of giving your HTML semantics. It’s a supplement, like Horny Goat Weed.
If your goat is already stoned and horny, you do not need to give him any Horny Goat Weed supplement. Similarly, If your HTML is already suitably semantic, you do not need to add ARIA on top. It’s redundant.
But you can use ARIA to add semantics where they are missing. For example, text that looks and is used like a first-level heading, but doesn’t use the <h1> element, would benefit from the ARIA attributes role="heading" and aria-level="1".
<div class="heading-1" role="heading" aria-level="1">Welcome to my web page</div>
Of course, you could just change the underlying element, which would save a lot of characters. So... yeah.
Director’s note: Templates
I only ever really use aria-level="x" when I am writing templates that need to have their heading level adjusted based on context. It’s important that design systems allow for this since components are modular and can be placed at different nesting levels in the document.
Using handlebars, I might compile the template using a level property:
<h2 class="component__heading" aria-level="{{level}}">{{label}}</h2>
You can also use ARIA to take away semantics that shouldn’t be there. A classic example is the layout table: a data table repurposed just to achieve a visual layout. Using role="presentation" on the outer <table> element removes the table semantics.
<table role="presentation">
<!-- a layout of some sort -->
</table>
Technically, layout tables should have been eradicated circa 2002. So, if you do encounter one, say, encased in fossilized tree resin or similar, please do not try to extract and revive it. That would be a f**king disaster.
Where people go wrong is by treating ARIA like garlic, adding it in vast quantities everywhere and expecting this to somehow make everything better. As with everything in the observed universe except garlic, the important thing is quality—not quantity.
A common error is to “MaKe A bUtToN aCcEsSiBlE” by giving an unsemantic <div> element the button role.
<div role="button">Click me</div>
The trouble is that you are telling screen readers the <div> is a button without making it behave like one. It can’t be focused using the keyboard, activated with the Enter key, or disabled correctly with the disabled property. It’s like pointing at a fire extinguisher and saying, “checkout out this goat.” Here, adding ARIA makes the interface more confusing, and less accessible.
The native <button> element has all of the behaviors you need already, and it already implicitly has the button role, meaning adding role="button" does f**k all.
<button>Click me</button>
Director’s note: type="button"
Some folks advocate adding type="button" to their <button>s as a matter of course. But it’s only really necessary where there is an ancestor <form> element: it ensures the form doesn’t consider the button as implicity of type="submit".
Where ARIA comes in useful is in extending semantics in ways that native HTML cannot. For example, we might want to add state to our generic button to make it a toggle button. The closest thing native HTML can offer is the checkbox with its checked state.
<label for="checkbox">
Toggle me
<input type="checkbox" id="checkbox" checked>
</label>
Director’s note: The for attribute
When you nest an input in a <label> you don’t strictly need the for/id relationship—or at least that’s what some will tell you. To be on the safe side and maximize compatibility, I always use for/id anyway.
It’s difficult to style, and is identified as an input to screen readers, so it’s not really appropriate.
Instead, we can add the pressed state to our button with aria-pressed, using JavaScript to toggle between the true and false values. Just because we’ve added an ARIA state attribute doesn’t mean we have to include role="button" alongside it. The state knows the role is there implicitly.
<button aria-pressed="true">Toggle me</button>
Director’s note: Implicit heading roles
You also don’t have to add role="heading" to a heading element just because you are using aria-level.
<h2 aria-level="3">Third level heading</h2>
Another mistake is to accidentally override important semantics. Unlike Schrödinger’s famously undead cat, HTML elements cannot be two things at once. That is, if you put a button role on an <h2>, it is no longer a second-level heading to the browser or any screen reader running. It’s just a button. And a broken one at that, because it doesn’t have the correct behaviors. AGAIN.
<!-- a broken button ↓ -->
<h2 role="button">Some content</h2>
The solution, as any bird who has housed their young in a rancid lattice of twigs, mud, and spittle will tell you... is nesting . By nesting a button element inside the <h2>, the semantics and behaviors of each element are preserved.
<h2>
<button aria-expanded="false">Some content</button>
</h2>
The screen reader still identifies the heading and applies the heading shortcut to it. The aria-expanded state tells the user whether the button has expanded or collapsed the content the heading introduces.
A quick way to reset the button styles and make the button look like the heading is to apply all: inherit to the button element:
h2 button {
all: inherit;
}
In summary...
ARIA can help make interfaces more compatible with assistive software like screen readers. Yes, that means blind people, but also visually impaired people, dyslexic folks, and anyone who wants to convert a web page into a podcast or audio book.
But... mostly you can do this, and more efficiently, with native semantic HTML. So only use ARIA to repair HTML or to add semantics native HTML doesn’t offer.
Remember that ARIA doesn’t make HTML accessible, it makes inaccessible HTML accessible. And don't forget that HTML accessibility is only a part of accessibility.
Finally: do not give sexual health supplements to goats, especially if they are already in a heightened state of arousal.