No ARIA Is Better Than Bad ARIA

ARIA (Accessible Rich Internet Applications) attributes exist to fill a real gap: describing custom, JavaScript-built interface patterns — a tab panel, a combobox, a custom dropdown — in a way assistive technology can understand, when native HTML has no built-in element that already does the job. Used correctly, it's essential. Used incorrectly, it actively makes things worse, because ARIA doesn't add information on top of what's already there — it overrides it, and a wrong override is worse than silence.

Why "some ARIA" isn't automatically an improvement

A native <button> already announces itself as a button, is already keyboard-operable, and already has correct focus behavior, all for free, with zero ARIA required. Adding role="button" to a <div> gives a screen reader the label "button" without any of the behavior — it won't be reachable by Tab without also manually adding tabindex="0", won't respond to Enter or Space without manually wiring that up too, and won't get any of the other default behaviors real buttons have. A <div role="button"> with none of that additional wiring is arguably worse than an unstyled, unlabeled <div> — it now confidently tells a screen reader user "this is an interactive button," and then fails to behave like one at all, which reads as a broken feature rather than a missing one.

The rule this leads to

The first rule of ARIA, often stated exactly this way in the accessibility community, is: don't use ARIA if a native HTML element or attribute already does what you need. A native <button>, <select>, <a href>, or <input> comes with correct semantics, keyboard behavior, and focus handling built in, tested across every screen reader and browser combination for decades — the same reason a modal built on <dialog> beats one assembled from <div>s. Reaching for ARIA to reconstruct that behavior on a generic <div> or <span> is almost always more work and less reliable than just using the native element in the first place.

Where ARIA genuinely earns its place

ARIA is the right tool specifically when there's no native HTML equivalent for the pattern you're building — a tab interface, a combobox with autocomplete, a toast notification, a custom slider. Even there, the safest path is to implement it against a documented pattern (the WAI-ARIA Authoring Practices Guide publishes tested reference implementations for exactly these patterns) rather than improvising the combination of roles, states, and keyboard handling from scratch, since these patterns have specific, non-obvious requirements that are easy to get partially right and functionally wrong.

A useful gut check

Before adding an ARIA attribute, ask whether a native element could do the same job with less code and no ARIA at all. If the answer is yes, that's very often the better fix — not because ARIA is bad, but because the native element already solved the problem correctly, and re-solving it with ARIA introduces new ways to get it wrong.