Forem: a11ySolutions

5 ARIA mistakes that make accessibility worse, not better

a11ySolutions — Wed, 06 May 2026 08:34:27 +0000

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?

Form accessibility: the checklist nobody actually uses (until users complain)

a11ySolutions — Thu, 30 Apr 2026 07:19:49 +0000

Forms are where accessibility debt becomes user abandonment.

A form can pass every automated scan and still be completely unusable
for a significant chunk of your users.

Here's what I see skipped constantly in real audits:

Placeholder text used as a label
When the field gets focus, the hint disappears. For users with cognitive disabilities or memory issues, that's a dead end.
Use <label> elements. Always.

Error messages that only exist visually
Red border + error text looks complete. But if the error isn't linked to the input via aria-describedby, screen readers announce nothing.
The user submits. Nothing happens. They don't know why.

Required fields with no accessible indicator
An asterisk (*) is a visual convention. Without aria-required="true" or a text equivalent, it means nothing to assistive tech.

Autocomplete missing on personal data fields
WCAG 1.3.5 exists. Most teams don't know it does. Name, email, phone, address, those fields need proper autocomplete
attributes. For users with motor disabilities, it can be the difference between completing the form or not.

Focus order that fights the visual layout
Tab order follows DOM order, not visual order. If your CSS grid or
flexbox rearranges things visually, keyboard users may be jumping around the form in a completely unexpected sequence.

None of these fail an automated scan.
All of them fail real users.

If you're doing form reviews, what's the first thing you check?

Great insights by Vitaly Skadorva! Our benchmarks confirm that moving to dynamic interaction testing is key, increasing finding precision from ~20% to over 80%. A must-read for true A11y!

a11ySolutions — Mon, 27 Apr 2026 16:24:17 +0000

Vitaly Skadorva

Apr 27

Accessibility Testing: Best Practices

#webdev #a11y #qa #testing

Comments 1

12 min read

Accessibility issues that automated tools won't catch (from real audits)

a11ySolutions — Fri, 24 Apr 2026 10:35:10 +0000

I run accessibility audits regularly. One pattern keeps showing up:

The most critical issues are never in the code. They're in the interaction.

Automated tools are genuinely useful, they catch structural and semantic
issues fast. But they don't simulate real user behavior. And that's where
things actually break.

Here are the failure patterns I find most often:

Keyboard traps in modals: focus gets locked inside a dialog with no
way out unless you know to press Escape (and even then, sometimes it doesn't
work).

Unpredictable focus jumps: after a button click or route change, focus
lands somewhere random. A screen reader user loses their place entirely.

Silent error messages: form validation runs, the error renders visually,
but aria-live is missing. Screen readers announce nothing.

Forms that validate but can't be completed: the markup passes the
scanner. Real users hit walls at step 2.

None of these show up in axe, Lighthouse, or WAVE. You only find them
when you actually use the product, keyboard only, screen reader on,
cognitive load simulated.

Accessibility isn't about passing a scan. It's about whether people can
complete critical flows.

How are you testing beyond automated tools in your projects?
Keyboard only passes? Screen reader sessions? Something else?