ARIA Usage

ARIA exposes meaning to assistive technology — but bad ARIA often harms more than missing ARIA.

01 — Purpose

Expose meaning to assistive technology

ARIA helps expose meaning and behaviour to assistive technology — used carefully it improves accessibility; used badly it creates confusion quickly.

Accessible Rich Internet Applications attributes bridge gaps when native HTML cannot express state, structure, or relationships. They are a supplement to the platform — not a replacement for it.

Start with semantic HTML and the accessibility standard before reaching for ARIA.

02 — Principles

Native HTML first

The platform already ships roles, states, and keyboard behaviour — use them before inventing custom widgets.

  • prefer semantic elements — button, nav, main, dialog
  • add ARIA only when native HTML cannot express the behaviour
  • keep states accurate — stale aria-expanded or aria-selected erodes trust
  • test with real interaction — keyboard, screen reader, and pointer

03 — Practice

Good ARIA usage

Minimal, accurate, and tied to actual UI state.

  • label controls with aria-labelledby or aria-label when visible text is insufficient
  • describe relationships — aria-controls, aria-describedby where they add clarity
  • sync live regions with visible updates — see live regions
  • use roles sparingly — only when no native element fits
  • follow established patterns — tabs, combobox, dialog — do not improvise roles

04 — Avoid

Bad ARIA harms more than missing ARIA

Incorrect or redundant ARIA misleads assistive technology.

  • unnecessary ARIA on elements that already have native semantics
  • incorrect roles — role="button" on a div without keyboard support
  • stale state attributes — expanded, checked, or selected out of sync with the UI
  • replacing native controls — custom checkboxes when input type="checkbox" works
  • aria-hidden on focusable content — users cannot reach what they need

05 — Close

No ARIA is better than bad ARIA

When in doubt, fix the HTML — not the attributes.

Review whether a native element or simpler structure solves the problem. If ARIA is required, document why, keep state in sync with your component logic, and verify with assistive technology.

See semantic HTML, live regions, and the accessibility QA checklist before release.