ACCESSIBILITY

Home › Glossary › Accessibility· 38 ·

ARIA

/ˈɑːriə/acronym (noun)

Filed underAccessibilityFront EndWeb Development

In brief · quick answer

ARIA (Accessible Rich Internet Applications) is a W3C specification that supplies the semantics missing in plain HTML for interactive widgets and dynamic content. ARIA attributes such as role, aria-label, aria-expanded, and aria-live tell assistive technologies what elements are and what they do. The first rule of ARIA: if you can use a native HTML element that already has the semantics built in, do that instead.

§ 1 Definition

ARIA (Accessible Rich Internet Applications) is a set of HTML attributes defined by the W3C that supplement native HTML semantics to make dynamic content and complex user interface widgets accessible to assistive technologies. ARIA enables developers to convey roles (role="button", role="dialog"), states (aria-expanded="true", aria-disabled="true"), properties (aria-label, aria-describedby), and live region updates (aria-live="polite") to screen readers and other AT. ARIA is not a replacement for semantic HTML. Native HTML elements such as <button>, <nav>, <main>, and <form> have implicit ARIA semantics built into the browser. Adding an ARIA role to a <div> that could have been a <button> is a code smell. The WCAG technique using ARIA is strictly for cases where the HTML spec does not provide the necessary semantics.

§ 2 The five rules of ARIA

The W3C defines five rules of ARIA use. Rule 1: If you can use a native HTML element with the required semantics and behaviour, do not use ARIA. Use <button> instead of role="button". Rule 2: Do not change native semantics. <h1 role="button"> confuses assistive technologies. Rule 3: All interactive ARIA controls must be keyboard accessible. role="button" on a <div> does not magically add keyboard handling. Rule 4: Do not use role="presentation" or aria-hidden="true" on focusable elements. Rule 5: All interactive elements must have an accessible name, typically via aria-label, aria-labelledby, or the native element's text content.

§ 3 Common ARIA attributes and their uses

aria-label provides an accessible name for an element when the visual label is not sufficient or not present. aria-labelledby references the id of another element to use as the label. aria-describedby references an element that provides a longer description. aria-expanded indicates whether a collapsible section is open or closed. aria-hidden removes an element from the accessibility tree (but not from the visual page). aria-live="polite" tells screen readers to announce changes in a region without interrupting. aria-live="assertive" interrupts the current announcement. role="alert", role="dialog", role="navigation", and role="main" provide landmark and widget semantics that native HTML may not cover in every case.

§ 4 ARIA and JavaScript: what you must handle

ARIA only provides semantics. It does not provide behaviour. If you add role="button" to a <div>, you must also ensure the element is focusable (tabindex="0"), responds to keyboard events (Enter and Space), and updates ARIA states (aria-expanded) when the UI state changes. ARIA does not replace JavaScript event handling. It tells assistive technologies what the element is and what state it is in, but the developer is responsible for all interactive behaviour.

§ 5 Note

ARIA is complex and easy to misuse. Incorrect ARIA can make accessibility worse than having no ARIA at all. Testing with actual screen readers is essential. Automated validators can catch some ARIA errors (such as missing required child roles) but cannot determine whether ARIA is semantically appropriate for the context.

§ 6 In code

<!-- Good: native HTML button with no extra ARIA needed -->
<button>Submit</button>

<!-- Also good: ARIA used correctly for a non-native control -->
<div
  role="button"
  tabindex="0"
  aria-expanded="false"
  onclick="toggleMenu()"
  onkeydown="handleKey(event)"
>
  Menu
</div>

<!-- Bad: Redundant ARIA on native element (unnecessary but harmless) -->
<button role="button">Submit</button>

<!-- Bad: ARIA instead of semantic HTML -->
<span role="heading" aria-level="2">Section Title</span>
<!-- Use <h2>Section Title</h2> instead -->

§ 7 Common questions

Q. Does ARIA fix everything?: A. No. ARIA adds semantics, not behaviour or appearance. A <div> with role="button" is still just a styled <div> unless you also handle keyboard events, focus management, and state updates. There is no shortcut to building accessible interactive widgets.
Q. Should I use ARIA on every element?: A. Only when necessary. Native HTML elements already carry the semantics screen readers need. <nav> is already a landmark. <button> is already an interactive control. Adding ARIA on top of native semantics is at best redundant and at worst contradictory and confusing.

Key takeaways

ARIA supplies semantics that native HTML cannot express.
The first rule: use native HTML elements before ARIA.
ARIA does not add behaviour. You must handle keyboard events and state management.
Wrong ARIA is worse than no ARIA.
Always test with real screen readers, not just validators.

How Atomic Glue helps

Atomic Glue developers are trained in proper ARIA usage, not as a crutch for poor HTML but as a precision tool for custom widgets. Our Web Development code reviews catch ARIA misuse before it ships. Get in touch for an audit.

Get in touch

# ARIA

Category: Accessibility (also: Front End, Web Development)

Author: Atomic Glue Team

## Definition

## The five rules of ARIA

## Common ARIA attributes and their uses

## ARIA and JavaScript: what you must handle

## Note

## In code

<!-- Good: native HTML button with no extra ARIA needed -->
<button>Submit</button>

<!-- Also good: ARIA used correctly for a non-native control -->
<div
  role="button"
  tabindex="0"
  aria-expanded="false"
  onclick="toggleMenu()"
  onkeydown="handleKey(event)"
>
  Menu
</div>

<!-- Bad: Redundant ARIA on native element (unnecessary but harmless) -->
<button role="button">Submit</button>

<!-- Bad: ARIA instead of semantic HTML -->
<span role="heading" aria-level="2">Section Title</span>
<!-- Use <h2>Section Title</h2> instead -->

## Common questions

Q: Does ARIA fix everything?

A: No. ARIA adds semantics, not behaviour or appearance. A <div> with role="button" is still just a styled <div> unless you also handle keyboard events, focus management, and state updates. There is no shortcut to building accessible interactive widgets.

Q: Should I use ARIA on every element?

A: Only when necessary. Native HTML elements already carry the semantics screen readers need. <nav> is already a landmark. <button> is already an interactive control. Adding ARIA on top of native semantics is at best redundant and at worst contradictory and confusing.

## Key takeaways

ARIA supplies semantics that native HTML cannot express.
The first rule: use native HTML elements before ARIA.
ARIA does not add behaviour. You must handle keyboard events and state management.
Wrong ARIA is worse than no ARIA.
Always test with real screen readers, not just validators.

## Related entries

Last updated July 2026. Permalink: atomicglue.co/glossary/aria