ARIA Roles
The role attribute is part of ARIA (Accessible Rich Internet Applications) — a set of attributes that patch accessibility semantics onto elements that don't have them natively. A role tells assistive technology what an element is or how it behaves, overriding or supplementing its native meaning.
The first rule of ARIA
The official first rule of ARIA use is: if a native HTML element or attribute already has the semantics and behavior you need, use it instead of re-purposing an element and adding ARIA to make it accessible.
<!-- Don't: recreate a button with ARIA and JavaScript --> <div role="button" tabindex="0" onclick="save()" onkeydown="...">Save</div> <!-- Do: use the native element, get behavior for free --> <button onclick="save()">Save</button>
When ARIA is actually needed
ARIA earns its keep for widgets HTML has no native equivalent for — tabs, comboboxes, custom dropdown menus, tree views, modal dialogs built from scratch — and for describing dynamic states native elements can't express alone.
Common roles
Role | Used for |
|---|---|
button | An interactive element that triggers an action (only needed if you can't use a real <button>) |
navigation | A block of navigation links (native <nav> already implies this) |
dialog | A modal or non-modal dialog window, usually paired with aria-modal |
alert | A time-sensitive, important message announced immediately to assistive tech |
tab / tablist / tabpanel | A custom tabbed interface's three moving parts |
search | A search landmark, typically wrapping a search form |
<!-- alert: announced immediately when it appears --> <div role="alert">Your changes have been saved.</div> <!-- dialog: a custom modal window --> <div role="dialog" aria-modal="true" aria-labelledby="dialog-title"> <h2 id="dialog-title">Delete item?</h2> ... </div>
"No ARIA is better than bad ARIA"
This well-known accessibility maxim means: an incorrect or contradictory role actively misleads assistive technology users, often worse than having no role at all. A role="button" on an element that doesn't behave like a button (no keyboard support, no expected keyboard events) tells screen reader users "this is a button" while the actual experience betrays that promise.
role="button" to a <div> does not add keyboard behavior. You still must add tabindex="0" and handle Enter/Space key presses manually — the role only changes what is announced, not how the element behaves.Use semantic HTML first; reach for ARIA only when no native element covers the pattern.
Never use ARIA to override the true nature of an element in a misleading way (e.g. role="heading" on a paragraph with no visual heading treatment).
Every role that implies interactivity also implies you must implement the matching keyboard behavior yourself.
Test with an actual screen reader — visually nothing changes when you add a role, so bugs are invisible without one.