ARIA: Use & Misuse
80% of homepages use ARIA — and those pages have 2× more errors than pages without. ARIA doesn't add behavior, only semantics. Misused ARIA is worse than no ARIA. Five rules: don't use ARIA if native works.
ARIA is extra labeling for custom controls — powerful, but easy to get wrong. Used badly it makes things worse, so reach for plain HTML first.
The five rules of ARIA (W3C):
- Don't use ARIA if a native HTML element works
- Don't change native semantics unless you really need to
- All interactive ARIA controls must be keyboard-accessible
- Don't use role="presentation" or aria-hidden="true" on focusable elements
- All interactive elements must have an accessible name
The most common ARIA errors: role="button" on a div without keyboard support, aria-hidden="true" on visible content, invalid role values, and missing required child roles (e.g., role="tablist" without role="tab" children).
Why this matters
80% of homepages use ARIA, and those pages have 2× more detected errors than pages without ARIA. ARIA doesn't add behavior — it only changes what assistive technology announces. A div with role="button" still needs tabindex, keyboard handlers, and focus styles. Misused ARIA is actively worse than no ARIA.
How to detect
Run axe DevTools — it catches invalid ARIA roles, missing required attributes, and conflicting roles. Then manually verify: does every ARIA role have the required states and properties? Are roles used on appropriate elements?