ARIA Attributes: When to Use Them (and When Not To)

ARIA (Accessible Rich Internet Applications) attributes can make custom web components accessible to screen readers. But misused ARIA is worse than no ARIA at all.

The first rule of ARIA

If you can use a native HTML element with the semantics and behaviour you need, do so. Don't repurpose an element and add ARIA when a native element exists.

A <button> is always better than <div role="button" tabindex="0">. Native HTML elements come with built-in keyboard handling, focus management, and screen reader support.

When ARIA is necessary

• Custom widgets — tabs, accordions, tree views, comboboxes that don't have native HTML equivalents
• Dynamic content — live regions (aria-live) to announce updates
• State communication — expanded/collapsed (aria-expanded), selected (aria-selected), current (aria-current)
• Labelling relationships — aria-labelledby, aria-describedby when standard label association isn't possible

Common ARIA mistakes

• Redundant roles — <nav role="navigation"> (nav already implies navigation)
• Wrong roles — <a role="button"> instead of just using <button>
• Missing required properties — role="slider" without aria-valuenow, aria-valuemin, aria-valuemax
• Hiding content incorrectly — using aria-hidden="true" on focusable elements
• Overusing aria-label — adding aria-label to elements that already have visible text

Essential ARIA for every website

• aria-label on icon-only buttons (e.g., hamburger menu, close button)
• aria-expanded on toggles (mobile nav, accordion headers)
• aria-live="polite" on notification areas and status updates
• aria-current="page" on the current page link in navigation