When to use ARIA

Last Updated: July 7, 2025

ARIA enables us to create rich experiences on the web for people with disabilities. Using it responsibly can be the difference between a usable or unusable website or application. But the overuse or misuse of ARIA comes up as one of the most common issues in accessibility code audits.

This page explains when you should and shouldn’t use ARIA.

Glossary

What is ARIA?

MDN web docs defines ARIA as:

a set of roles and attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.

ARIA supplements HTML so that interactions and widgets commonly used in applications can be passed to assistive technologies when there is not otherwise a mechanism. For example, ARIA enables accessible JavaScript widgets, form hints and error messages, live content updates, and more.

When semantic HTML doesn’t provide the necessary roles or attributes needed to make an element accessible by default, ARIA is used to fill the gap.

The five rules of ARIA

Don’t use ARIA unless you have to. Follow these rules, as defined by the W3C (Using ARIA):

1. If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

   1. Explanation: Always lean on HTML first. Applying ARIA generally means more complexity for decision making and outcomes for assistive technologies.

   2. Ask yourself: “Am I using custom components when semantic HTML would suffice?”

2. Do not change native semantics, unless you really have to.

   1. Explanation: Changing the native semantics of an element, means it won't work as expected, and the team that's changed it needs to take responsibility for ensuring it works properly. This creates the need for extra testing, user research and engineering time. There can be good reasons to do this, but tread carefully.

   2. Ask yourself: “Why am I changing the native behavior of this element?”

3. All interactive ARIA controls must be usable with the keyboard.

   1. Explanation: Basic keyboard functionality provides essential compatibility between any interactive component on the web and assistive technology. Without it, the interactive component won't work.

   2. Ask yourself: “Can I use a keyboard to access this component?”

4. Do not use role="presentation" or aria-hidden="true" on a focusable element.

   1. Explanation: Similar to keyboard functionality, removing the ability to move focus to an interactive element makes it useless to assistive technology. That's what role="presentation" or aria-hidden="true" do.

   2. Ask yourself: “Can I focus on the element while using assistive technology (like a screen reader)?”

5. All interactive elements must have an accessible name.

   1. Explanation: An Accessible Name for an interactive control helps assistive technology users understand what the control is and does. Without it, users have to make guesses about what controls do.

   2. Ask yourself: “Does this element have a name?”

How to use ARIA on VA.gov and VA mobile applications

1. Use design system components first. If you need to make a custom component, seek guidance from accessibility specialists.

2. Use the existing properties provided by components. If you need to add custom markup or attributes in a component, file an issue on GitHub with the design system, or ask about it in the team's Slack channel.

3. The most difficult ARIA challenges happen when two or more common components get combined into a new component, and create a complex experience that's harder to translate without the use of sight or other senses.

4. Pay attention to accessibility guidance in both the VA Design System and US Web Design System. It will often add boundaries around what's possible and more difficult to accomplish with a certain component.

5. Use accessibility annotations during the design process to think through any ARIA customizations.

6. Using ARIA or Accessibility Labels on mobile platforms helps with Veterans know what's happening on a page, what something means and how they can interact. If you're not using ARIA for this, consider altering your design.

Resources

• Accessibility in the VA Design System

• Accessibility annotations for VA.gov applications

• Live regions (pptx)

• W3C: Using ARIA

• Web.dev: ARIA and HTML

Help and feedback

• Suggest content changes to this page.

• Submit new Platform Website content.

• Get help from the Platform Support Team in Slack.

• Submit a feature idea to the Platform.