Digital Accessibility Index: Learn where the world’s leading brands fall short on accessibility.

See Report

Why No ARIA Is Better Than Bad ARIA

Aug 28, 2024

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. 

Use our free Website Accessibility Checker to scan your site for ADA and WCAG compliance.

Powered By

Recent posts

Accessibility Tips: Don’t Use Subheadings Because of How They Look

Sep 5, 2024

Writing Alt Text for Hyperlinked Images

Sep 4, 2024

Making Content More Accessible for Second-Language Learners

Aug 27, 2024

Not sure where to start?

Start with a free analysis of your website's accessibility.

GET STARTED