ARIA (Accessible Rich Internet Applications) is a set of attributes that add accessibility semantics — roles, states, and properties — that native HTML can't express. But the most important ARIA rule is: prefer native HTML first.
Save
Save
Native elements come with correct roles, keyboard behavior, and focus for free. Reach for ARIA only when no native element does the job.
<!-- 1. Roles — what an element IS (for custom widgets) -->
<div role="tablist"><div role="tab" aria-selected="true">Tab 1</div></div>
<!-- 2. States — current condition (dynamic) -->
<button aria-expanded="false" aria-controls="menu">Menu</button>
<input aria-invalid="true" aria-describedby="err" />
<!-- 3. Properties — relationships / labels -->
<input aria-label="Search" />
<div aria-labelledby="heading-id"></div>
<div aria-live="polite">3 results found</div> <!-- screen reader announces updates -->
<div aria-live="assertive" role="alert">Error saving!</div> <!-- interrupts -->
This is genuinely useful ARIA: telling screen readers about content that changes without a page reload (search results, toasts, validation errors).
Incorrect ARIA is worse than none — it gives screen reader users false information. And ARIA changes only semantics, never behavior: role="button" on a <div> doesn't make it focusable or clickable; you must add tabindex and key handlers yourself.
Use semantic HTML for the 95% case; use ARIA to fill the gaps for custom widgets (tabs, comboboxes, menus) and to announce dynamic updates via live regions.
Follow the rules — prefer native, don't change native semantics needlessly, keep states in sync, and never apply a role you don't fully implement.