What is ARIA and when should you use it?

ARIA accessibility helps make custom and dynamic web interfaces understandable to people using assistive technologies. It is most useful when native HTML cannot communicate everything users need to interact with a component. This guide explains when ARIA accessibility is appropriate, when native HTML is the better choice, how roles and attributes are used, and what developers should check during implementation and testing.

What is ARIA in HTML?

ARIA stands for Accessible Rich Internet Applications, usually referred to as WAI-ARIA. It is a W3C specification that defines semantics developers can use to make web content and applications easier for assistive technologies to interpret. Checking how these semantics are implemented can form part of ongoing accessibility compliance monitoring as websites and their interfaces change.

Browsers already understand the semantics of native HTML elements. A <button> is recognised as a button, for example, while heading elements communicate the structure and level of headings. This information can then be exposed to assistive technologies such as screen readers.

ARIA in HTML provides additional semantics when the existing markup cannot adequately communicate an element's purpose, state, or relationship with other content. Developers add this information through roles, states, and properties within the markup.

How does ARIA accessibility work?

Browsers use information from HTML and ARIA to build an accessibility tree that assistive technologies can access. This tree represents elements through information such as their name, role, state, and relationships with other content.

ARIA can supplement or change the information represented in this tree. If an expandable control uses aria-expanded, for example, its current expanded or collapsed state can be exposed programmatically as the interface changes.

The accessibility tree is separate from the visual presentation of the page. Someone using a screen reader may therefore receive information about an element's purpose or state that is not displayed as visible text.

What are ARIA roles, states, and attributes?

ARIA roles communicate what an element represents. Examples include dialog, tab, alert, and treeitem. A role can give assistive technology information that would otherwise be unavailable from the underlying element.

ARIA states describe information that can change as someone interacts with a component. aria-expanded, for example, can change between true and false as content opens and closes.

ARIA properties provide other information about an element or its relationship with content elsewhere on the page. Examples include aria-describedby, which associates an element with descriptive content, and aria-controls, which identifies an element controlled by another element.

Roles, states, and properties need to correspond with the component they describe. Particular roles can support or require specific ARIA attributes, so the appropriate combination depends on the interface being built.

When should you use ARIA?

ARIA should have a defined accessibility purpose. W3C's first rule of ARIA is to use a native HTML element or attribute when it already provides the required semantics and behaviour.

ARIA becomes useful when an interface needs accessibility information that HTML cannot adequately communicate on its own. Common examples involve custom components, changing states, accessible names and descriptions, and dynamic updates.

When a custom component needs additional semantics

Web applications can contain components that do not map neatly to a single native HTML element. Complex tab interfaces, tree views, and some other custom widgets can require additional accessibility semantics.

ARIA roles can identify the different parts of these components. A custom tab interface, for example, can use appropriate roles to identify the tab list, individual tabs, and associated panels.

ARIA attributes can then provide information about relationships or current states within the component. This allows assistive technologies to interpret a custom interface in a way that its underlying HTML may not communicate by itself.

When an interface state changes

Some controls change state without loading another page. A section might expand, a toggle might switch on, or an item might become selected. Visual styling can make these changes apparent to some users, but the state also needs to be available programmatically. Consider an expandable control:

<button aria-expanded="false">
 Delivery information
</button>

When the associated content opens, the value can change:

<button aria-expanded="true">
 Delivery information
</button>

The ARIA attribute needs to remain synchronised with the interface. Leaving aria-expanded="false" after opening the content would communicate an inaccurate state to assistive technology.

Other state attributes serve different purposes. aria-selected can identify a selected item within certain components, while aria-pressed can communicate the state of a toggle button.

When an element needs an accessible name or description

Some interface elements need an accessible name or description that cannot be determined adequately from their existing content.

An icon-only search button is a simple example. A magnifying-glass icon may communicate its purpose visually while providing no meaningful text from which an accessible name can be determined.

An accessible name can be supplied where necessary:

<button aria-label="Search">
 [search icon]
</button>

ARIA attributes can also associate an element with text elsewhere on the page. aria-labelledby can reference content that provides an accessible name, while aria-describedby can associate supplementary information with an element.

Developers should first check whether visible text or native HTML already provides the necessary information. An unnecessary aria-label can override other accessible naming information and change what assistive technology announces.

When dynamic updates need to be communicated

Web pages can change without moving focus or reloading. Form validation messages, loading statuses, confirmation messages, and other updates may therefore appear visually without automatically drawing a screen reader user's attention.

ARIA provides ways to identify content whose updates should be communicated. Live regions and roles such as status or alert can be appropriate depending on the type and urgency of the information.

For example, a status message can communicate the result of an action while allowing the user's current focus to remain in place. An alert may be appropriate for information requiring more immediate attention.

These features need to be used selectively. Frequent or unnecessary announcements can interrupt users and make an interface harder to follow.

When should you avoid using ARIA?

ARIA can make an interface less accessible when its semantics do not match the component's content or behaviour. W3C summarises this risk with the principle that "No ARIA is better than Bad ARIA." There are several situations where adding ARIA creates unnecessary complexity or inaccurate accessibility information.

When native HTML already provides the right semantics

Semantic HTML should usually be the starting point for common controls and page structures. If a control performs a button action, use <button> where possible. If something navigates to another location, an <a> element with an appropriate href already provides link semantics and behaviour.

Compare:

<div role="button">Save</div>

With:

<button>Save</button>

Assigning role="button" can cause the first element to be exposed as a button, but it does not provide all the behaviour users expect from a native button. The developer would need to implement the necessary keyboard and focus behaviour separately. The native element already provides those foundations.

When ARIA duplicates or conflicts with existing semantics

Adding ARIA where HTML already communicates the correct information can be unnecessary. More significant problems arise when an ARIA role, state, or property contradicts the actual interface.

A role that misidentifies a component can cause assistive technology to announce the wrong type of control. An inaccurate state can tell someone that content is expanded when it is closed. An incorrect accessible name can obscure the purpose communicated by visible content.

ARIA attributes also have defined requirements. Particular attributes only accept certain values, and some roles require or prohibit specific attributes. The information exposed through ARIA should therefore correspond with both the underlying element and the interface presented to the user.

When ARIA is being used to compensate for broken interaction

ARIA describes how a component should be understood by assistive technology. HTML and JavaScript still determine how that component behaves.

This distinction becomes particularly important with custom widgets. A tab interface may expose the correct tab, tablist, and tabpanel roles while remaining difficult to use if keyboard focus does not move between its tabs as expected.

A custom dialog can also have the correct role and accessible name while allowing users to interact with content behind it or providing no clear way to close it.

W3C describes assigning an ARIA role as making a promise about the behaviour users can expect. Developers need to implement the interaction pattern associated with that role as well as exposing its semantics.

How do you test ARIA accessibility?

Testing ARIA accessibility should establish whether the information exposed to assistive technology accurately represents the interface and changes as users interact with it. Browser accessibility tools can provide an initial view of the accessibility tree. Check important components for the expected names, roles, states, and relationships.

Interaction testing should then confirm that:

• Interactive controls can be reached and operated with a keyboard.
• Focus moves predictably where a component requires focus management.
• Dynamic ARIA states update when the interface changes.
• Accessible names communicate the correct purpose.
• Descriptions and relationships reference the intended content.
• Status messages and other dynamic updates are communicated appropriately.

Screen reader testing can reveal whether this information remains understandable without relying on the visual interface. A component can contain technically valid ARIA attributes while still producing confusing or incomplete information in use.

Browser and assistive technology support can also vary between ARIA patterns. Testing relevant combinations is particularly important for custom components that depend heavily on WAI-ARIA behaviour.

How can Welcoming Web identify ARIA accessibility issues?

ARIA accessibility problems can be difficult to spot visually because a page may appear to work as expected while exposing incorrect information to assistive technology.

Welcoming Web scans for supported ARIA accessibility issues, including invalid or prohibited attributes, missing required attributes, invalid attribute values, and inappropriate roles. It can also identify ARIA attributes that are unsupported or incorrectly applied for a particular role.

For example, a scan can detect an ARIA attribute containing a value that is not permitted by the specification. It can also identify supported cases where a role is missing information required for assistive technologies to interpret it correctly.

For supported issue types, Welcoming Web provides AI-assisted remediation suggestions that teams can review while investigating detected problems. Recurring monitoring can surface detectable ARIA issues introduced as components and pages change.

Automated checks cannot determine whether every ARIA implementation works effectively in context, so some interactions still require manual evaluation. Run a free accessibility scan to identify supported ARIA and other accessibility issues on your website.

Using ARIA without creating new accessibility barriers

Before adding ARIA, identify the information an assistive technology user is currently missing. Then check whether native HTML can provide it. If ARIA is necessary, choose the role or attribute that describes that specific requirement and make sure the component's behaviour matches the semantics you expose. Test the finished interaction instead of assuming valid markup means an accessible result.

See whether ARIA issues are present on your own website. Run a free accessibility scan with Welcoming Web to identify supported ARIA issues and other detectable accessibility barriers.