It’s tempting to think of ARIA (Accessible Rich Internet Applications) as the one-stop solution for all your accessibility needs. After all, ARIA exists to help developers create web content that works better for people who use assistive technology, like screen readers. But here’s the catch: if you misuse ARIA—or in places where it isn’t needed—you can end up making your site less accessible, not more.
This post will explain why semantic HTML should always be your go-to approach, when and why ARIA is beneficial, the most common ARIA mistakes, and best practices for getting it right. By the end, you’ll see how “less is more” often applies to ARIA and why sticking to native elements can save you—and your users—a lot of trouble.
What Is ARIA (and Why Does It Matter)?
ARIA stands for Web Accessibility Initiative – Accessible Rich Internet Applications. Created by the World Wide Web Consortium (W3C), ARIA provides a set of roles, states, and properties that help assistive technologies (like screen readers) understand the meaning and function of different elements on a webpage. It’s beneficial for complex or dynamic interfaces that native HTML elements don’t fully cover—such as custom sliders or tab interfaces.
However, the real power of ARIA depends on how it’s used. Applying ARIA roles in the wrong places or mislabeling states can lead to confusion and errors. Users relying on screen readers might hear incorrect information about what’s on the page or even miss out on essential controls. If you’re not cautious, you could do more harm than good.
Why Semantic HTML Should Be Your First Choice
Before jumping into ARIA, remember that semantic HTML is the foundation of accessible web design. Native elements, like <header>, <nav>, <button>, and <footer>, come with many built-in features that screen readers and other assistive tools already understand.
What is Semantic HTML?
It refers to HTML elements that clearly describe their meaning. For instance, a <nav> element signals that it contains navigation links. A <button> says, “I’m something clickable!” to both users and screen readers.
Why Does it Matter?
When you use semantic elements, you’re using markup that browsers and screen readers know how to interpret. This often means you don’t need ARIA at all—because everything is already handled for you.
Real-world Example
If you need a button, just use <button> instead of a <div> with role= "button". Screen readers automatically identify a <button> as a button, while a <div> is just a generic container. Adding a role= "button" to that <div> can work, but it’s extra code and is often less reliable than using a <button> in the first place.
By relying on these built-in elements, your code is simpler and more intuitive. You’re also less likely to cause confusion when you mix ARIA roles with native roles.
When (and Why) ARIA Is Actually Needed
So, if semantic HTML is so powerful, why do we have ARIA at all?
Filling the Gaps
HTML is great, but it’s not perfect. Some interactive elements—like complex sliders, tab panels, or sortable tables—aren’t natively supported (or are only partially supported) by standard HTML tags. ARIA helps fill in these gaps by providing additional metadata.
Roles, States, and Properties
ARIA is split into three main categories: roles (what is this thing?), states (what is its current condition?), and properties (how does it behave?). These allow screen readers to give users a clearer picture of what’s happening on the page.
Example: Tabs and sliders
If you’re building a tab interface from scratch, you might rely on a series of <div> elements. You’d need ARIA attributes like role= "tablist", role= "tab“, and role= "tabpanel", plus properties like aria-selected= "true" or aria-hidden= "true" to show which tab is active.
Ultimately, ARIA becomes crucial when the default HTML elements don’t cover the level of interactivity or complexity you need. That might be a custom widget or a specialized interface that doesn’t map neatly to existing HTML tags.
The Most Common ARIA Mistakes (and Why They’re a Problem)
Misusing Roles
Sometimes, developers add ARIA roles to elements out of habit, without stopping to see if the native element would have worked better. If you set role= "button" on a <div>, you must also manually manage keyboard interactions and focus states. If you don’t, assistive technology users may be unable to click or navigate to this “button” effectively.
Example
<!-- Not so good -->
<div role="button" tabindex="0" onclick="doSomething()">
Click me
</div>
<!-- Better -->
<button onclick="doSomething()">Click me</button>
Using a <button> means you get keyboard focus, click events, and screen reader recognition by default—no extra ARIA or scripting needed.
Redundant or Conflicting Roles
Many elements come with built-in roles. A <nav> element is understood as “navigation,” and a <ul> is understood as a list. If you add role= "navigation" to a <nav>, you’re restating something already known. In some cases, overriding a native role with a custom role can even interfere with how assistive technologies interpret the element.
Example
<!-- Not so good -->
<nav role="navigation">
<!-- Navigation links here -->
</nav>
<!-- Better -->
<nav>
<!-- Navigation links here -->
</nav>
Here, adding role= "navigation" is unnecessary and could create confusion in some tools.
Incorrect State Management
ARIA states, like aria-expanded or aria-checked, must accurately reflect the element’s real condition. If your dropdown menu is closed but you have aria-expanded= “true”, a screen reader user will hear that the menu is open—even though it isn’t. This mismatch can be very disorienting.
Example
<!-- Not so good: says it's expanded when it's actually closed -->
<button aria-expanded="true" onclick="toggleMenu()">Menu</button>
<!-- Better: toggle the value dynamically with JavaScript -->
<button aria-expanded="false" onclick="toggleMenu()">Menu</button>
Make sure your script updates aria-expanded to reflect the actual state of the menu (true when open, false when closed).
ARIA Overload
Adding too many ARIA attributes can clutter the information that screen readers must process. For instance, overusing aria-live regions can cause screen readers to constantly read out changes that might not be important. This can frustrate users and cause them to miss critical content.
Example
<!-- Not so good: multiple live regions announcing frequent updates -->
<div aria-live="polite">Update 1</div>
<div aria-live="polite">Update 2</div>
<div aria-live="polite">Update 3</div>
<!-- Better: only announce genuinely important changes -->
<div aria-live="polite" id="importantUpdates"></div>
If you really need to announce multiple updates, try grouping them or letting users opt-in.
Misusing aria-hidden
aria-hidden= "true" tells screen readers to ignore an element. If you add this attribute to interactive content—like a button, form field, or link—you’re effectively locking out users who rely on assistive tech.
Important: Hiding something visually is not always the same as hiding it from screen readers. Don’t use aria-hidden if the content is still necessary for some users.
Example
<!-- Not so good: Interactive element is hidden from screen readers -->
<button aria-hidden="true" onclick="doSomething()">Buy Now</button>
<!-- Better: If you need to hide it visually for some reason, do so with CSS,
but keep it accessible to screen readers. -->
<button class="visually-hidden" onclick="doSomething()">Buy Now</button>
(“Visually hidden” classes typically hide elements from sighted users but keep them available to assistive tech.)
Why “No ARIA” is Often the Best Choice
The golden rule is this: bad ARIA is worse than no ARIA at all. Why? Because at least with no ARIA, the user experience reverts to the default behaviors of native HTML, which assistive technologies are designed to understand. But if you add incorrect ARIA roles or states, you can mislead screen readers entirely.
In many cases, the standard HTML element does everything you need. By default, a <button> is keyboard-accessible, announces itself as a button, and can have an accessible label. Adding role= "button" to a <div> only means more overhead for you and possibly less clarity for users.
Best Practices for Using ARIA the Right Way
Use Native HTML First
Always check whether you can use a built-in HTML element. This approach is simpler to code, more reliable, and better for accessibility out of the gate.
Example
Instead of:
<div role="button" tabindex="0">Submit</div>
Use:
<button>Submit</button>
No extra attributes, no confusion—just a straightforward button.
Be Precise with Roles and States
If you must use ARIA, choose the exact role that matches the purpose of your element. Also, keep an eye on the current state—like aria-expanded, aria-checked, or aria-selected—and update it only when something changes.
Example
<button aria-expanded="false" aria-controls="menu" onclick="toggleMenu()">Menu</button>
<ul id= "menu" hidden>
<li>Home</li>
<li>Services</li>
<li>Contact</li>
</ul>
In this example, setting aria-expanded= "false" on the button shows it’s not expanded. When the user clicks, you can switch that to true in your JavaScript.
Don’t Add ARIA Where It’s Not Needed
If an element already serves a clear function, adding a role that duplicates it is just noise for screen readers.
Example
<!-- Not so good -->
<ul role="list">
<li>Item 1</li>
<li>Item 2</li>
</ul>
<!-- Better -->
<ul>
<li>Item 1</li>
<li>Item 2</li>
</ul>
A <ul> is already recognized as a list by assistive technology.
Test with Real Assistive Tech
Tools like automated accessibility checkers are helpful, but they can’t catch everything. The best way to confirm your site’s accessibility is to test it with screen readers (like NVDA, JAWS, or VoiceOver) and try navigating entirely with a keyboard. If you can, get feedback from people who actually use these tools every day—they can point out mistakes or obstacles you might miss otherwise.
Conclusion
Using ARIA incorrectly can do more harm than good. In fact, it can make websites less accessible and confusing for users who rely on screen readers. The first step to building an accessible website is to stick with semantic HTML wherever possible. If you need ARIA—especially for complex custom widgets—be sure to use it carefully, accurately reflecting each element’s true roles and states. Then, test your work with real users and assistive technologies to make sure you’re making things better, not worse.
Following these guidelines helps create a smoother experience for every visitor, including those using assistive technology. Remember: if you can solve your problem with native HTML, do that first. If not, ARIA can be a fantastic tool—just be sure you’re using it correctly.
Need Help with Web Accessibility?
Making a website accessible can be tricky, especially when it comes to knowing how and when to use ARIA. 216digital specializes in web accessibility, from ARIA best practices to full WCAG compliance. If you’re ready to take the next step toward a more inclusive web experience, reach out to us today! Let’s work together to ensure your site remains welcoming—and functional—for every user.
