If you don’t need WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) markup, don’t use it. Semantic HTML is perfectly sufficient for most websites, and it’s more widely supported than ARIA.
Simple, right? Not necessarily; there are quite a few cases in which ARIA is the right tool for the job. And for developers, a few lines of ARIA markup can seem like a simple way to make sure that web content works with screen readers and other assistive technologies (AT).
If you’re thinking about using ARIA, you should understand how bad ARIA can impact the user experience.
Misused ARIA can break the experience for screen reader users
Since ARIA is designed specifically for communicating important information to assistive tech. You’ll use it to define live regions, mark dynamically generated content, and describe other website features that can’t be described with native HTML alone.
But since ARIA is designed for accessibility, minor implementation errors may directly affect your users' experiences. You’re directly telling AT how to behave — and if you’re sending the wrong commands, the software may not recognize the mistake.
That can impact users in dozens of ways. Here are a few of the most common examples:
Incorrect or Misleading Roles
Using the wrong role could prevent AT users from understanding how your content functions. For example, using role="button" on a non-interactive element can mislead screen reader users into thinking it is clickable.
Similarly, applying role="heading" to a non-heading element can disrupt the document structure perceived by the screen reader, making navigation difficult. And misusing the landmark “application" role may render a site completely unusable.
Overuse of ARIA
Overusing ARIA can create clutter. For screen reader users, too much “noise" can be obnoxious. People want to hear important context that makes the website more navigable and intuitive, but too much information can distract from the experience.
For instance, excessively using aria-live regions can result in a constant stream of announcements, overwhelming users who are trying to focus on the primary content.
Incorrect State Management
Incorrect use of ARIA states and properties, like aria-expanded or aria-checked, can send false information to your users. For instance, if an expandable section is marked as collapsed when it's actually open, a screen reader user may miss important content.
Conflicting ARIA and Native Semantics
Applying ARIA attributes that conflict with the inherent semantics of an HTML element can lead to confusion. This is an especially common mistake for developers who overuse non-semantic HTML (namely, the div and span elements).
For example, assigning role="button" to an <a> tag (anchor element) can create ambiguity for screen reader users. The purpose of role=”button" is to tell screen readers that the element is a button, but the role provides no button functionality on its own — and if the element still operates like an anchor element, the user might become confused.
In this case, the HTML <button> or <input> elements with type=”button" are generally more appropriate. But once again, we’re butting up against one of the best practices of ARIA: If you’re not using semantic HTML appropriately, ARIA isn’t going to fix your website.
Related: 4 Questions to Ask Before Using ARIA
While ARIA isn't always necessary, it can be an incredible tool
As we’ve discussed, ARIA isn’t a magic solution. However, if you’ve got a complex website with dynamic content, ARIA might just be your best friend.
It allows you to define elements that aren’t natively defined by HTML, which is freeing. You can build just about anything that you’d like, provided that you follow the best practices. ARIA isn’t a burden; it removes limitations on designers and developers, and in some cases, it’s essential.
With that said, remember: If you use ARIA, you must make a commitment to test your markup. That means checking your spelling (and remember, ARIA roles are case-sensitive). It also means running tests with an actual screen reader; those tests should be performed by a user with significant screen reader experience. Ideally, you should test with multiple screen readers and web browsers.
It’s a lot to take on — and if you truly need ARIA, it’s worth the effort. If you’re considering ARIA implementation, we encourage you to reach out to our team. Send us a message to connect with an expert.
