ARIA Roles in Practice: When to Use Them and When to Skip Them

ARIA (Accessible Rich Internet Applications) is a powerful way to make custom widgets accessible — and a powerful way to break perfectly accessible HTML. The five rules of ARIA exist because both happen constantly.

The first rule of ARIA

"If you can use a native HTML element, do that instead of repurposing an element and adding an ARIA role."

<button> already has role="button", keyboard support, focus styles, and the right accessibility tree. <div role="button" tabindex="0"> requires you to reinvent all of that — usually badly.

ARIA roles you'll actually use

• role="dialog" + aria-modal="true" — for modals
• role="tablist" / "tab" / "tabpanel" — for tabbed UIs
• role="alert" — for important status messages
• role="navigation" — when <nav> isn't enough

Useful aria-* attributes

<button aria-expanded="false" aria-controls="menu-1">Menu</button>
<ul id="menu-1" hidden>...</ul>

<input aria-describedby="hint-1">
<small id="hint-1">8+ characters</small>

<span class="badge" aria-label="3 unread messages">3</span>

Common ARIA mistakes

• role="button" on a div without keyboard handlers
• aria-hidden="true" on focusable elements (traps screen reader users)
• Duplicating native semantics (role="button" on a <button>)
• Using aria-label on elements that already have visible text

Live regions for dynamic content

<div aria-live="polite" id="status"></div>
<script>
  document.getElementById('status').textContent = 'Saved.';
</script>