Skip to content
Home Top 5 ARIA Implementation Errors

Top 5 ARIA Implementation Errors

a man working on laptop - top 5 ARIA implementation errors

Modern web design includes lots of rich and dynamic interactions. Websites and applications include menus, tabbed interfaces, carousels, dynamically updating content etc. To make rich and dynamic interactions accessible, websites and applications extensively use ARIA roles, states and properties. Be it ARIA landmarks, specifying accessible names for user interface controls via the aria-label attribute or use of live region attributes.

At BarrierBreak, we work with different industries, such as Insurance, Ecommerce, Edtech, Information & Communication Technology, Banking & Finance etc. When we perform accessibility testing of these web pages, we come across several incorrect implementations of ARIA attributes. Such incorrect implementations are found not only in components but also in static web page content. So, I decided to share the Top 5 ARIA Implementation Errors through this blog post.

Error 1: Inappropriate use of ARIA roles, States or Properties

Such an open-ended error statement, isn’t it? Yes, it is … But it is true. Web pages with multiple errors of inappropriately defined ARIA role, state and properties are identified while performing accessibility audits.

Some of the errors that we come across include role “button” is defined for a semantically marked up heading, aria-has popup is defined for navigation links, aria-pressed is set to “false” for a toggle button in the pressed state and so on. Sounds like easy fixes … aren’t they? Yes, most of such errors are relatively easy to fix. But wait before we talk about fixing, let’s first understand how these errors impact users with disabilities.

When a heading is identified as a button to screen reader users, they will try to activate it and at most times it won’t have any action associated with them. Moreover, important structure information about the heading will not be identified for screen reader users. Users can’t jump to the heading with their heading navigation keys either.

Use of aria-haspopup attribute on navigation links will identify the presence of a menu for screen reader users. When users activate the link they will find themselves on a different page or even a different section on the current web page. Not a critical error for sure but an error that hampers the user experience for screen reader users.

Imagine that you activate a toggle button to Mute your microphone, but the assistive technology identifies the state of the button as “Not pressed”. For users with visual impairments, it is like doing the right thing, but action is not being carried out … but, the microphone does get muted. Such an awkward situation for users as they don’t know the correct state of the button.

The Using ARIA guidance document is what I’ll recommend developers to refer to. These errors can be fixed easily:

  • Example 1: Remove role “button”. In most cases there is no functionality associated with the headings. If the error is found for an Accordion, than  refer ARIA’s Authoring Practices Guide (APG) for accessible implementation patterns.
  • Example 2: Navigation links are not menus and thus aria-haspopup attribute must not be defined for such links. If you plan to create navigation menus, then refer to the ARIA APG for accessible implementation patterns.
  • Example 3: In the case of toggle buttons, value of aria-pressed attribute should change on user interaction. Sounds simple but often such errors go unnoticed as visually things are looking fine. However, programmatically the code is not updated. Here I’ll recommend conducting user testing with people with disabilities to make sure such errors are identified and necessary fixes are implemented at the code level!

Error 2: Expand/Collapse State not defined.

This error is specifically about the state of a component not defined programmatically. This type of error is found generally for accordions, disclosure, menus etc. components. Be it FAQs on a website that are implemented as accordions, the hamburger menu and disclosure components. On activating these components, content is either shown or hidden below.

Visually the content is displayed immediately after the component and is therefore easy to understand for sighted users but what about users with visual impairments? They are left high and dry. They interact with the component, but the state information is not communicated to them. As a person with low vision, I’ll try to navigate down using a screen reader to see if there is some content available. But isn’t it frustrating to do so each time one interacts with such a component?

The solution is defining aria-expanded attribute for such expandable/collapsible components programmatically. When the component is in a collapsed state, set aria-expanded to “false” and when the component is in an expanded state, set aria-expanded to “true”. The key is to update the attribute’s value on user interaction.

Error 3: Role not defined.

In this category, errors are often found where a button coded using <span> or <div> tags lack a role, tabs within a tabbed interface don’t have a role defined, custom radio buttons and checkboxes don’t have role defined and so on.  Role information is what assistive technologies make use of to let their users know about the type of content they are interacting with. Is it a heading, link, button, tabbed interface, toolbar etc. Role is important for users to know because based on the role they will understand how to interact with the given content.

Based on role, assistive technology users will press the Spacebar key to check box and use the Arrow keys to navigate between tabs. When role is not defined, commands given by voice input users might not be executed and screen reader users will not know which keystroke to press to interact with the content. For example, a voice input user gives a command to click on “I agree checkbox” the required action will not be executed in the absence of role information. The assistive technology will not be able to find any such checkbox.

The solution is to define a suitable role for each component. The role information is baked right in for native HTML elements, but this is not the case for custom components. Role needs to be defined explicitly to let users know the type of component they are interacting with. “Add to cart” is what a screen reader will read out if role is not defined and “Add to cart button” is what the screen reader will read out when role “button” is defined. Makes a huge difference for assistive technology users!

Error 4: Missing ARIA Attributes

Different types of ARIA attributes are found missing while reviewing web content for Accessibility. Some of the errors under this category include aria-label not defined for navigation landmarks, aria-current not defined for pagination controls as well as navigation links, aria-hidden is not used to hide decorative icons, aria-describedby is not used to associate the form error message with respective input fields etc. These ARIA attributes can enhance the user experience for Assistive technology users and make rich interactions much more smoother.

In the absence of different ARIA attributes, screen reader users won’t know which navigation landmark they are currently accessing, decorative icons will be read out for them, and form error messages won’t be read out as they navigate through the form. None of these errors are blockers but they are frustrating errors which will result in a poor experience for Assistive technology users.

I’ll recommend if you have multiple navigation landmarks (role “navigation” or <nav>) than please specify an accessible name for each navigation landmark. This is found very useful by screen reader users as they know whether they are accessing primary navigation, footer navigation or a breadcrumb navigation. Similarly, hide decorative icons from Assistive technologies. This can be done by specifying aria-hidden = “true” for these icons.

When form errors are displayed inline, it is very important to associate each error text with the respective input field. Assign a unique ‘id’ for the container used for displaying error text and reference it via the aria-describedby attribute of the input field. In the case of pagination controls and navigation links, users need to know which page they are currently on. Often this information is presented visually by using a different style, but this needs to be defined programmatically too! Use aria-current = “page” to make this information available for assistive technology users.

Error 5: Inappropriate use of ARIA Attributes for Carousels

Carousels are common on the web, aren’t they? Yes, they are and so are the ARIA errors associated with carousels. Some of the carousel related errors that we often come across are the content is not identified as a carousel, dynamically changing content is not announced, and current state of the slider picker control is not defined programmatically. There are so many different implementations that we see on the web but the above mentioned the common ARIA related errors that are found during Accessibility reviews.

When a blind person does not know that they are interacting with a carousel, then how can we expect them to understand that they need to navigate back -n-forth in order to read the updated content. Yes, there are no specific roles available for a carousel or a slide, but this information can be made available in different ways for sure.

A carousel generally comprises of previous, next and slide picker controls. Most carousels will at the minimum have previous and next controls to help users navigate between the slides.

When users activate these controls slide content changes, this dynamically updating content is often not picked up by screen readers. When change in content is not identified, a blind person will not know what exactly is going on.

Lastly, the current state of slide picker control is not defined programmatically. How does this impact users? Lack of state information will result in screen reader users being left wondering about which slide they are currently on. Again, this is in most cases done perfectly visually by applying different styles but not defined programmatically. So, if user has activated slide 2, they will not know if the slide 2 control is in the “selected” state.

All these errors can be fixed by applying a few tricks. So, let’s understand how these can be fixed:

  • Example 1: To make sure presence of a carousel is identified for assistive technology users, place the carousel in a <div> element and define either role “region” or role “group”. Next specify an accessible name for the region or group and in the name communicate that it is a carousel, “Products carousel” or “Services carousel”. No matter if there is no specific role of carousel is not there the key is to make the information for all users. Accessibility can be implemented in different ways!
  • Example 2: Use aria-live region attribute to make the dynamically updated content available for screen reader users. Here one needs to be careful that aria-live “off” is specified for an auto-rotating carousel else the noise will be too much for screen reader users to listen to too. With regards to changes in slide content based on user interaction, i.e., when users clicks on different slide picker control, aria-live “polite” should be used to make the change in content available to screen reader users. Head over to ARIA APG – Carousel implementation to check out on how to make this happen! With regards to changes in slide content based on user interaction, i.e., when users clicks on different slide picker control, aria-live “polite” should be used to make the change in content available to screen reader users. Head over to ARIA APG – Carousel implementation to check out on how to make this happen!
  • Example 3: To communicate the state of the currently selected slide picker control, two different techniques can be used. First if the carousel uses tab implementation, aria-selected “true” needs to be specified for the current slide and aria-selected “false” for the inactive slides. Second if the carousel uses a button implementation, then the selected state can be communicated by adding hidden text “selected” for the currently active slide.

All in all, the above ARIA errors are pretty common, and we understood that they can be fixed relatively easily. Use native HTML in the first place and if you decide to use ARIA then make sure that the implementation is free from errors. Remember “No ARIA is better than Bad ARIA”.

This article by Priti Rohra is a part of our BB Geek series where BarrierBreak team members share their expertise on accessibility and inclusion, drawing from their extensive experience in the field.

2 thoughts on “Top 5 ARIA Implementation Errors”

  1. Dear Sir/Madam,

    Thanks for wonderful article of
    Top 5 ARIA Implementation Errors – Leader in Offshore Accessibility Testing | Section 508 Compliance | WCAG Conformance | BarrierBreak.
    Which came across to me through the BGFI whatsapp group.
    From the point of view of accessibility the following observation I have, which is mention as follows.
    Below the heading 2 of
    Error 5: Inappropriate use of ARIA Attributes for Carousels
    There are 3 items are mention as an examples. But only the first item is mark with list and remaining 2 items are out of list.
    I believe this is an error of incorrect list marking so please make note of same and correct it which is very helpful for the community.


    Sudesh Bandekar

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top