ARIA & Keyboard

When HTML isn't enough

ARIA (Accessible Rich Internet Applications) adds accessibility information that native HTML can't express — roles, states, and labels for custom widgets like tabs, modals, and live regions.

The first rule of ARIA

No ARIA is better than bad ARIA. If a native element conveys the semantics you need, use it. Adding role="button" to a <div> forces you to recreate everything a real <button> gives you: focus, Enter/Space handling, and screen-reader announcements.

Labels

Two attributes supply accessible names:

• aria-label — a string read directly: aria-label="Close".
• aria-labelledby — references the id of visible text on the page, keeping the name in sync with what sighted users see.

<button aria-label="Search">🔍</button>

<span id="lbl">Card number</span>
<input aria-labelledby="lbl">

Keyboard access

Every interactive element must be reachable and operable by keyboard alone:

• tabindex="0" — add a custom element to the natural tab order.
• tabindex="-1" — focusable via script but not via Tab (useful for moved targets).
• Avoid tabindex values above 0 — they disrupt the document order.

Focus management in SPAs

In single-page apps, "page" changes don't trigger a reload, so screen readers don't announce them. After navigation, move focus to the new heading or main region so users know the view changed. Use :focus-visible to show focus rings only for keyboard users, not mouse clicks.

A visible focus indicator is a legal and moral requirement, not a styling afterthought. Never set outline: none without providing a clear replacement.