What you need to know about ARIA and how to fix common mistakes

If you’ve never heard of ARIA, need a beginner’s introduction, or are a developer needing some common examples, you’re in the right spot.

In this article, we go over the ARIA basics that everyone working with websites should know. Then, we get a little more advanced with an introduction to ARIA for people editing HTML. We end with some ARIA examples for developers.

Rather watch a video on ARIA? Watch our What ARIA is and its impact on accessibility to learn what ARIA is, why it matters, and examples that show why ARIA matters.

What everyone should know

ARIA, or Accessible Rich Internet Applications, is HTML used to make webpages more accessible. Not all HTML elements have accessibility built into them, so ARIA is used to add that accessibility.

In fact, WebAIM’s web accessibility evaluation tool, WAVE, has an entire category dedicated to showing you where ARIA is on a website. That’s because using ARIA incorrectly can actually make a website less accessible, so it’s important anyone editing HTML is familiar with ARIA.

Wait! Before you keep going…

At this point, you know what ARIA is, and you know that incorrect ARIA can actually make your website less accessible. So, if you don’t work with HTML, you’re done! You have the ARIA basics you need.

If you build websites or work with HTML, keep going to learn more about ARIA, the impact of using ARIA incorrectly, and how to handle common ARIA situations.

Introduction to ARIA for people editing HTML

Let’s start with an example of how ARIA is used. Then, we’ll go over the number one rule of ARIA. To end this introduction, we’ll show you how incorrect ARIA impacts user’s with disabilities.

Example of how ARIA can make a website more accessible

Here’s an example of how ARIA is used to make a page more accessible. In the HTML below and the accompanying image of the web page, there are two navigations using the nav HTML element. Without any ARIA added, assistive technology, like a screen reader, would announce both as “navigations” because of the HTML nav element.

But, the aria-label attribute renames the element. Now, the screen reader would announce “User Menu” for the top navigation and “Main Menu” for the left navigation. The assistive technology user can now differentiate between the two menus.

<nav aria-label="User Menu" class="top-bar-right navbar">
<nav aria-label="Main Menu" id="left-sidebar" class="left-sidebar">

Back to top

The number one rule of ARIA

There are actually five rules when it comes to using ARIA. The first rule may sound funny, but it’s don’t use ARIA. This rule really means if there’s a native HTML element or attribute that’ll get you the behavior you’re looking for, then just use the HTML element or attribute.

For example, ARIA is often used incorrectly when people make buttons from divs or links. Instead, the native HTML <button> element should’ve been used.

To see a more detailed example of this rule in action, check out the button example below.

Back to top

Impact of using ARIA incorrectly

ARIA requires HTML knowledge to use it correctly. If it is added haphazardly or just copy and pasted in, it can cause significant problems for users with disabilities.

Watch the video below to see how incorrect ARIA affects users using a screen reader.

Back to top

Biggest developer pitfall when it comes to ARIA

We mentioned this above, but it’s worth saying again before we dive into the examples. The biggest developer pitfall when it comes to ARIA is adding it haphazardly or just copying and pasting it from other code.

The saying to code by is, “No ARIA is better than bad ARIA.” In fact, the WebAIM million survey found that home pages with ARIA averaged 41% more accessibility errors. The moral of the story is if ARIA is used incorrectly, it can actually make your site less accessible.

So, if you don’t know what the ARIA role, state, or property does, or how it will work with your specific website, don’t use it, or research and test it before using it.

Let’s get into the examples.

Back to top


A div or a href can be assigned the ARIA role="button". Assigning this role doesn’t add any functionality to the button. It just makes the screen reader announce to the user that it’s a button. A screen reader user will then expect the button to activate when they select spacebar or enter.

For example, in the code below, a Print button is made using a div element. The div has the ARIA role=button, but adding this doesn’t make the button function how it needs to in order to be accessible.

<div role="button" id="action">Print Page</div>

For more information, check out MDN’s button role article or MDN’s HTML button element article.

Common problem

ARIA is often used incorrectly when people assign role="button" to divs or a href. Instead, the native HTML <button> element should’ve been used.

For the div button above to be accessible, the developer has to add javascript to give the functionality a true button has, which is to activate when a keyboard user selects spacebar or enter.

That’s a lot of work to get a div to function as a button. Especially when the HTML <button> element is already programmed to be selected when a keyboard user selects spacebar or enter.

So, the solution here is don’t use ARIA. Instead, if you have a button, use the <button> element. Now, a screen reader user knows it’s a button and can access it using a keyboard without any extra work on the developer’s part. Here’s what the new code would look like:

<button type="button">Print</button>

Watch our ARIA impact video above to see how incorrect use of role="button" effects a screen reader user.

Back to top


aria-expanded tells users that use assistive technology when something like a navigation or accordion is collapsed or expanded. For example, in the code below, aria-expanded="false" when the navigation menu is closed and aria-expanded="true" when it’s opened.

<button type="button" class="navbar-toggler collapsed" data-bs-toggle="collapse" data-bs-target="#main-nav-collapse" aria-expanded="false" aria-controls="main-nav-collapse">Menu</button>
<button type="button" class="navbar-toggler" data-bs-toggle="collapse" data-bs-target="#main-nav-collapse" aria-expanded="true" aria-controls="main-nav-collapse">Menu</button>
Collapsed navigation menu.
Expanded navigation menu.

For more information, check out MDN’s aria-expanded article.

Common problem

The common problem with ARIA expanded is when code is copied and pasted, and ARIA expanded is mistakenly set to the opposite value. For example, when a navigation is closed aria-expanded="true" and when it’s open aria-expanded="false".

What’s tricky about this is the navigation or accordion works as normal with a mouse. The only way you’d see there’s an error is if you were testing with a screen reader. So, if you see aria-expanded in your code, make sure the right value is set correctly for each state of the button or toggle.

Back to top


Using aria-hidden="true" will remove an element from the accessibility API, which means assistive technology like screen readers won’t announce it. But, it will still be visible to visual users. For example, in the code below, a decorative icon is hidden.

<i class="fas fa-chart-area" aria-hidden="true"></i>

For more information, check out MDN’s aria-hidden article.

Common problem

Unfortunately, it’s common for aria-hidden="true" to be copied and pasted over from code or be added without knowing what it does. This ends up hiding elements that assistive technology should have access to. And, because the element still works with a mouse, the problem is rarely found.

Watch our ARIA impact video above to see how incorrect use of aria-hidden effects a screen reader user.

Back to top


aria-label renames the element. As we saw above, a screen reader would announce an HTML <nav> element as “nav.” But, if the <nav> element has aria-label="Primary Navigation", the screen reader will announce it as “Primary Navigation.”

<nav aria-label="Primary Navigation" class="left-sidebar"></nav>

For more information, check out MDN’s aria-label article.

Common problems

We went over a good use of aria-label above. But, there’s a common aria-label error when it comes to forms.

This example form uses labels and has ARIA that isn’t needed. Let’s take a look:

 <form action="/action_page.php">
    <label for="fname" aria-label="First name">First Name</label>
    <input type="text" id="fname" name="firstname" placeholder="Your name..">

    <label for="email" aria-label="Last name">Email</label>
    <input type="email" id="email" name="email" placeholder="Your email..">
    <input type="submit" value="Submit">

Because this form has an HTML label for each input, we actually don’t need aria-label. Assistive technology will use the label text.

So, the problems we often see are:

  1. Even though aria-label isn’t needed, it’s still used.
  2. The aria-label is wrong like the email input above, which has aria-label="Last name".

It’s common for the wrong aria-label to get assigned because the code was copied and pasted and then changed. The issue isn’t caught because, visually, everything looks okay. Now, assistive technology users think that field is their last name instead of email, which completely breaks the interaction.

Watch our ARIA impact video above to see how incorrect use of aria-hidden effects a screen reader user.

Back to top


Each webpage has a native keyboard navigation, which is made up of focusable elements like links, buttons, and form fields. A user can then tab through the focusable elements in the order they appear in the HTML, so it’s important the HTML structure matches the visual structure.

Any HTML element can have the tabindex global attribute added to it. Tabindex defines what elements are focusable, the order they are tabbed, or completely hides the element from being accessed by a keyboard.

For more information on how tabindex works, check out MDN’s tabindex article or WebAIM’s keyboard accessibility article.

Common problems

The common problems with tabindex are:

  1. Accidentally making important content inaccessible by a keyboard when trying to create a custom tabindex.
  2. Adding headings and other non-focusable items using tabindex. While this might be done with good intentions, it makes the page less accessible because it now doesn’t work how someone using a keyboard would expect the page to work.

Here’s an example page with a bad tabindex. You can tab through the content to experience what it’s like. The code is also available at the bottom of the page.

Back to top

How to start making HTML with ARIA accessible on your website

This activity is made for websites. It’s not made for Canvas courses because Canvas courses typically shouldn’t use ARIA.

  1. Locate all the instances of ARIA on your website. If you’re a Pope Tech user, run an HTML or PDF detail report and configure it for only ARIA-related results. Otherwise, use WebAIM’s website evaluation tool to check individual pages for ARIA. If you’re checking individual pages, it might be helpful to keep track of them in a spreadsheet.
  2. Go through the ARIA instances and determine if they are accessible.
  3. If they aren’t accessible, assign updating it to someone.
  4. Make an achievable goal depending on how many ARIA instances need to be fixed and share that goal with your team or office.
  5. If you don’t have one already, schedule a monthly accessibility check-in (even if it’s just you) to celebrate progress and remove blockers.
  6. Identify who regularly works in HTML and make a plan with them on how to make any new content accessible going forward.

Back to top

Screen reader testing resources

Here are free resources to do your own screen reader testing:

Read more about ARIA

Key takeaways

  • Not all HTML elements have accessibility built into them, so ARIA is used to add accessibility.
  • There are five rules when it comes to using ARIA.
  • The first rule is don’t use ARIA, which just means if you can use a native HTML element or attribute to get the behavior you’re looking for, then just use the HTML element or attribute.
  • Using ARIA incorrectly can actually make your website less accessible. Remember, “no ARIA is better than bad ARIA.”

Want to be part of the conversation?

Share questions, feedback, and experiences on Twitter
using #AccessibilityFocus.

Sign up for our newsletter to get emails with accessibility content similar to this article. If you subscribe, we’ll email you web accessibility insights or things we learn a few times a month. You can unsubscribe at any time.

    Check any page for accessibility errors

    Check all your pages at once with Pope Tech. Your web accessibility data is ready in just a few minutes.

    Make accessibility part of content editors’ and developers’ process with WebAIM’s WAVE extension tool.