There's a rule in accessibility that doesn't get enough attention:
No ARIA is better than bad ARIA.
Adding ARIA attributes without understanding them doesn't help assistive tech, it actively misleads it. Here are the mistakes I find most often in real audits:
1. role="button" on a div — without keyboard support
If you give something a button role, screen readers announce it as a button.
Users expect to activate it with Space or Enter.
If your div only handles onClick, keyboard users get announced a button they can't press. Use <button>. That's what it's there for.
2. aria-label that duplicates visible text — badly
<button aria-label="Click here to submit the form">Submit</button>
Screen readers read the aria-label, ignoring "Submit". Now your button is "Click here to submit the form", verbose, inconsistent, and confusing in a list of controls.
If the visible label is accurate, you don't need aria-label.
3. aria-hidden="true" on focusable elements
Hiding something from the accessibility tree while leaving it focusable creates a ghost, keyboard users can tab to it, but screen readers announce nothing. That's worse than not hiding it at all.
4. aria-live on everything
aria-live="assertive" interrupts whatever the screen reader is doing to announce the update. Useful for critical alerts. Catastrophic for
status messages, loading indicators, or anything non-urgent.
Most of the time, aria-live="polite" is what you want, or nothing at all.
5. Decorative icons without aria-hidden
An icon inside a button with no aria-hidden forces screen readers to
announce the SVG path or file name alongside the button label.
<svg aria-hidden="true"> is two words. Use them.
No ARIA is better than bad ARIA.
Before reaching for it, ask if a native HTML element solves it first.
What ARIA mistakes do you see most in code reviews?
Top comments (0)