ARIA best practices
WAI-ARIA is a W3C specification that adds roles, states and properties to HTML for assistive technologies. Golden rule: “no ARIA is better than bad ARIA”. Use the native element first.
The key rules
aria-label: accessible name for a button without visible text; it must contain the visible text when there is one.aria-expanded: open/closed state of an accordion or menu.role="alert": important notification announced immediately.aria-live: dynamic updates (polite,assertive,off).- Don’t overdo it: ARIA only where native HTML is insufficient; an ARIA role requires the matching keyboard behaviour.
Code example
<!-- Prefer native -->
<button type="button" aria-expanded="false" aria-controls="panel">Details</button>
<div id="panel" hidden>…</div>
<!-- Icon button: accessible name -->
<button type="button" aria-label="Close"><svg aria-hidden="true" focusable="false">…</svg></button>How to test
Inspect the accessibility tree in developer tools, then listen with NVDA or VoiceOver. RGAA criteria: 7.1 (assistive-technology compatibility) and 7.5 (status messages). Cheat sheet: ARIA Authoring Practices Guide.
Frequently asked questions
Why avoid ARIA when possible?
A native button brings role, focus and keyboard activation for free. Misapplied ARIA degrades the experience for screen-reader users.
What is an accessible name?
The text assistive technologies announce for an element; it comes from content, a label or aria-label.