What Is ARIA and When to Use It

ARIA — Accessible Rich Internet Applications — is a W3C specification that lets you add roles, states and properties to HTML so that assistive technologies understand the meaning and current condition of your interface. It is what makes a JavaScript-built tab set, dropdown or live notification understandable to a screen-reader user. But ARIA has one defining limitation and one defining rule. The limitation: ARIA changes only how an element is announced — it adds no behaviour, no keyboard support, no styling. The rule, known as the first rule of ARIA: do not use ARIA if a native HTML element already does the job. Used correctly, ARIA fills genuine gaps; used carelessly, it makes a site less accessible than no ARIA at all. This guide explains what ARIA is, when it earns its place, and the common mistakes that quietly break pages.

It is the semantic companion to what web accessibility is and why it matters and connects closely to the custom-widget work in how to make a website keyboard accessible.

What ARIA is

ARIA is a specification maintained by the W3C's Web Accessibility Initiative. It defines a vocabulary of HTML attributes that describe user-interface semantics that plain HTML cannot always express — particularly for the dynamic, scripted interfaces that dominate modern web apps. When a screen reader encounters an element, it builds a picture from the accessibility tree, a parallel representation of the page derived from the DOM. ARIA attributes modify that tree, changing what the element is, what state it is in, and how it relates to other elements, so the screen reader announces it correctly.

The vital thing to internalise from the outset is what ARIA does not do. It does not make an element focusable. It does not make it respond to the keyboard. It does not change how it looks or behaves for a mouse user. It changes one thing: the semantics reported to assistive technology. Everything else — focus management, key handling, visual state — you still have to build yourself. ARIA is a labelling system, not a behaviour system, and most ARIA bugs come from forgetting that.

Roles, states and properties

ARIA's vocabulary falls into three kinds of attribute:

• Roles define what an element is. role="button", role="navigation", role="dialog", role="tablist", role="alert" — each tells assistive technology how to treat and announce the element. A role is generally set once and does not change.
• States describe an element's current, changeable condition. aria-expanded="true" on a disclosure control, aria-checked="false" on a custom checkbox, aria-selected="true" on a tab, aria-disabled="true" on an inactive control. States change as the user interacts, and your JavaScript must keep them accurate.
• Properties describe more stable characteristics or relationships. aria-label gives an element an accessible name; aria-labelledby and aria-describedby point to other elements that name or describe it; aria-required marks a field as mandatory; aria-controls links a control to what it affects.

The line between states and properties is sometimes blurry, and you do not need to police it — what matters is keeping the values accurate and updated. An aria-expanded that says false while the menu is visibly open is worse than useless; it tells the screen-reader user the opposite of the truth.

The first rule of ARIA: native HTML first

The most important guidance about ARIA is when not to use it. The W3C's authoring practices state it directly as the first rule of ARIA:

If you can use a native HTML element or attribute with the semantics and behaviour 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.

The reason is that native elements come with accessibility built in and tested across browsers and assistive technologies. A <button> is already focusable, already activates on Enter and Space, already announces as a button, and already exposes its disabled state — for free, with no ARIA. A <nav>, <main>, <input type="checkbox">, <select> or <details> likewise carries correct semantics and, where relevant, keyboard behaviour out of the box.

Re-creating that with ARIA on a <div> means manually adding a role, tabindex, key handlers and state management — far more code, and far more opportunities to get it subtly wrong. So the discipline is: reach for the correct native element first, and only consider ARIA when no native element expresses what you need. This is the same principle that underpins how to make a website keyboard accessible: native elements are the shortest path to an accessible, operable control.

When ARIA genuinely helps

ARIA exists because native HTML cannot cover everything, and in three situations it is exactly the right tool.

1. Custom widgets with no native equivalent

HTML has no element for a tabs interface, a combobox with autocomplete, a tree view, a menu button, a carousel or a slider with two handles. When you build one of these, ARIA supplies the roles and states that tell a screen reader what it is and how it is behaving — role="tablist", role="tab", role="tabpanel" with aria-selected for a tab set, for instance. The WAI-ARIA Authoring Practices Guide (APG) documents the expected structure, roles, states and keyboard interaction for each common pattern, and following it is the safe route. Remember, though: the ARIA describes the widget, but you must still write the keyboard behaviour (arrow keys to move between tabs, Enter/Space to activate, focus management) by hand.

2. Live regions for dynamic updates

When content changes without a page reload — a search result count updates, a form shows a validation message, a toast notification appears, a chat message arrives — a sighted user sees it, but a screen-reader user may not be told. ARIA live regions solve this. Marking a container with aria-live="polite" tells the screen reader to announce changes inside it at the next convenient pause; aria-live="assertive" (or role="alert", which implies it) interrupts immediately for urgent messages like errors. Live regions are one of ARIA's most valuable contributions, because dynamic announcements are something native HTML simply cannot do.

3. Accessible names and descriptions

Sometimes an element's purpose is clear visually but not in text a screen reader can use. An icon-only button (a bare magnifier glyph) has no text content, so aria-label="Search" gives it an accessible name. A group of fields can be named by a heading with aria-labelledby. A complex input can point to helper or error text with aria-describedby so that text is read along with the field. These naming and describing properties are the ARIA features you will reach for most often in otherwise-standard pages — and they are central to how to build accessible forms.

A pattern-to-ARIA reference

To make the "when" concrete, here is how common situations map to the right approach — including the many cases where the answer is native HTML, no ARIA:

Pattern / need	Recommended approach
A clickable control that performs an action	Native <button> — no ARIA needed
Site navigation region	Native <nav> — no ARIA needed (or role="navigation" on older markup)
A checkbox	Native <input type="checkbox"> — no ARIA needed
Icon-only button with no visible text	<button> plus aria-label="…"
Tabs interface (no native element)	role="tablist" / role="tab" / role="tabpanel" + aria-selected + keyboard handling
Disclosure / accordion toggle	<button> with aria-expanded toggled in JS
Modal dialog	<dialog> if suitable, else role="dialog" + aria-modal="true" + focus management
Announcing a status message	aria-live="polite" region, or role="status"
Announcing an urgent error	role="alert" (assertive live region)
Naming a group of related fields	<fieldset>+<legend>, or aria-labelledby
Linking help/error text to a field	aria-describedby pointing at the text's id
Marking a field invalid	aria-invalid="true" plus a described error message

The pattern is clear: for anything HTML can express, use HTML; reserve ARIA for the genuine gaps.

Common ARIA mistakes

Because ARIA overrides what assistive technology would otherwise report, getting it wrong is actively harmful — hence the well-known maxim "no ARIA is better than bad ARIA." The recurring errors:

• Roles without behaviour. Adding role="button" to a <div> but no tabindex and no key handlers produces something that announces as a button but cannot be focused or activated by keyboard. The promise is broken.
• Wrong or invented roles. Applying a role that does not match the element's real purpose (or a role that does not exist) makes the screen reader announce something false, which is more confusing than silence.
• Redundant ARIA on native elements. Writing <button role="button"> or <nav role="navigation"> is at best pointless and at worst can interfere with the element's native semantics. The native element already says it.
• Suppressing real content. An aria-hidden="true" placed on something a user needs, or on a focusable element, hides it from screen readers while it remains operable — a serious inconsistency.
• Stale states. Setting aria-expanded or aria-checked once and never updating it as the user interacts, so the announced state diverges from reality.
• Over-labelling. Piling on aria-label where visible text already exists can override and replace that text, sometimes with something worse, and can desynchronise what is seen from what is heard.

Every one of these makes the experience worse for the very users ARIA is meant to help, which is why the safe defaults are: prefer native HTML, follow the APG patterns when you do use ARIA, keep states accurate, and test with an actual screen reader (NVDA, VoiceOver or JAWS) rather than trusting that the attributes are doing what you intended — exactly the verification stressed in how to check if a website is accessible.

The bottom line

ARIA is a W3C vocabulary of roles, states and properties that communicates UI semantics to assistive technology — and nothing more. It adds no behaviour, so it must always be paired with real keyboard and focus code. Live by the first rule of ARIA: use native HTML wherever it expresses what you need, because native elements are accessible by default. Reserve ARIA for the genuine gaps — custom widgets (following the WAI-ARIA Authoring Practices), live regions for dynamic updates, and accessible names and descriptions when visible text cannot do the job. And remember that bad ARIA is worse than none, so keep it correct, keep states current, and verify with a screen reader. For the foundations, see what web accessibility is and why it matters; for related practice, how to build accessible forms.

Want to see how your site's markup holds up to a WCAG accessibility check, alongside SEO and performance? Analyse any URL with StackOptic — one report, free, no sign-up.