Accessible Rich Internet Applications (ARIA) was designed to fill the gaps where HTML alone cannot convey meaning. By providing roles, states, and properties, ARIA enables developers to communicate important information to assistive technologies like screen readers, ensuring that dynamic content and rich web applications remain usable for people with disabilities.
When applied correctly, ARIA is invaluable. Think of it as asphalt for the potholes in HTML: it smooths over missing semantics. For example, HTML has no native attribute to describe whether a disclosure widget is collapsed or expanded. ARIA addresses this elegantly with aria-expanded="true" or "false".
The trouble begins when developers lean on ARIA as a crutch rather than a surgical solution. Many, especially when first learning accessible coding, attempt to “ARIA everything,” sprinkling aria-label on non-interactive elements or duplicating information already conveyed by semantic HTML. While some of these missteps cause little harm, others introduce genuine confusion and even break accessibility.
I see this frequently in my work scoping accessibility implementations. One recent example stood out:
A simple card featured text and a button. On the surface, nothing unusual. But the code revealed that the button included an aria-label overriding the visible link text.
<div>Virtual employee benefits cards</div>
<a href="..." class="..." aria-label="Talk To Sales">
Discover Wazoo
</a>As a result, a screen reader announced:
“Virtual employee benefits cards, Talk to Sales, link“
The mismatch between the aria-label and the visible text led to confusion. Users expecting a “Talk to Sales” page were instead sent to a completely different destination. The culprit? A leftover ARIA attribute, likely introduced when the card’s purpose changed but the markup wasn’t updated. Worse still, the aria-label was unnecessary in the first place; the visible link text was sufficient.
This is ARIA misuse in a nutshell: well-intentioned but ultimately harmful.
The lesson is clear: learn ARIA deeply before deploying it broadly. HTML should always be the first tool of choice. Use ARIA only when necessary, and only with precision. Done right, it enhances accessibility. Done wrong, it undermines it.
ARIA is not about more code, it’s about smarter code.