You’re Probably Not Testing Accessibility the Way Users Experience It

R3TICULAR — Mon, 13 Apr 2026 22:41:48 +0000

Most frontend developers today use tools like Axe, WAVE, or Lighthouse to test accessibility.

And that’s a good start.

But there’s a gap that these tools don’t really cover:

They don’t tell you what a screen reader user actually hears.

The Problem: Accessibility ≠ Announcement

Let’s take a simple example:

From a rule-based perspective, this passes:
-It has an accessible name
-It uses a semantic element

But what does a screen reader actually announce?

NVDA: “Submit Payment, button”
VoiceOver: “Submit Payment, button”
JAWS: “Submit Payment, button”

So far, so good.

Now let’s tweak it slightly:

Submit

This might still pass some basic checks.

But a screen reader might announce:

“Submit”

Not:

“Submit, button”

That’s a completely different experience.

The Real Pain: Testing Screen Readers Is Hard

If you’ve ever tried to properly test this, you know the workflow:

Install NVDA (Windows),
Maybe use JAWS (paid, also Windows)
Use VoiceOver (macOS),
Navigate everything with a keyboard
Listen carefully to announcements
Repeat across browsers and flows

It works—but it’s pretty slow, manual, hard to automate, and OS dependent

In practice, what happens is:
Run Axe/Lighthouse → fix obvious issues then
Do minimal screen reader testing (if any), then
Ship- badaboom.

The problem?

Most accessibility issues that affect real users show up in how things are announced, not just whether rules pass.

A Missing Layer in the Tooling

What’s missing is something in between:
Not just rule-based linting
Not full manual screen reader testing but-

A way to preview how your markup will be interpreted by assistive technologies

Recently in being fed up with this, I started building a tool to help with this exact problem:
👉 getspeakable.dev

You can paste in HTML and see predicted announcements for:
• NVDA
• JAWS
• VoiceOver

For example:

🔍

Might produce something like:

“button”

Instead of:

“Search, button”

Which immediately tells you:
the element has no accessible name

Noted that, this isn’t a replacement for real screen reader testing.

Instead, it fits earlier in the process alongside linting (Axe & lighthouse) tools, then using speakable for audible authentication/regression, and the n manual screen reader testing to validate real user experience.

Catching them earlier is significantly cheaper than fixing them later.

DEV Community: R3TICULAR

You’re Probably Not Testing Accessibility the Way Users Experience It