Services · Compliance & standards
Screen Reader Testing by People Who Use One Every Day
For the team that wants to know what a screen reader really announces on their site, sentence by sentence, from somebody who has listened to one every working day for years.
What We Keep Finding
Here is a simulation worth thirty seconds of your time. Your screen reader lands on a control and says "button". Just "button". Now pick the one that empties your cart rather than the one that pays for it.
And here is the part that decides whether a tool could ever have caught it. W3C files fifteen live automated rules under the criterion that governs a control's name. Ten of them name it as a requirement, and seven of those ten test only whether a name exists rather than whether the name means anything. A button called "button" passes all seven. That is not a gap in somebody's scanner. It is the conformance-tested rule set working exactly as written, and it is why this pass exists.
The failures users report themselves line up with it. Asked what makes web content most difficult, screen reader users put CAPTCHA first, then interactive elements behaving unexpectedly, then links and buttons whose names make no sense, then screens that change without warning. Three of those four are things only a person can hear happening.
So our testers are blind professionals, and the session comes back in their own words with every blocker screenshotted where it happened. They are not simulating the experience. It is theirs.
What We Check
- Work your key journeys end to end on NVDA and on VoiceOver
- Record what each control actually announces, so its name, its role, and its state
- Judge whether the name means anything, which is the test no automated rule performs
- Catch the silent failures, meaning unannounced updates, dead live regions, and lost focus
- Note where the reading order stops matching what sighted users see
- Name the exact screen reader, browser, and version in the report, so it stays checkable
What You Get
Every service on this site runs the same three-pass engine: an automated scan, an expert review of all 55 WCAG 2.2 A and AA rules, and a hands-on session with a professional blind screen-reader user. You get one report with every finding screenshotted, ranked by user impact, and linked to its fix. Your team fixes, we verify: the re-audit is half price within 3 months.
The format is not a mystery either. Read the sample report before you spend anything.
The Honest Limit
One honest limit, and it has a number on it. Screen reader behavior is a property of a combination rather than of a page, so we run the mainstream pairs rather than every combination in existence. A Rapid Audit runs one pairing and a Standard Audit runs both NVDA and VoiceOver. JAWS is the single most-used primary screen reader, at 40.5% of users surveyed. If your audience sits mostly there, tell us when we confirm scope, because that changes what we set up rather than what we charge. And our sessions are desktop-based, while most screen reader users also use one on a phone, so the mobile half is outside this engagement.
What It Costs
Rapid Audit: $499, up to 10 pages you pick, report in 5 business days. Standard Audit: $1,499, up to 25 pages in 10 business days. Flat rates, no discovery calls, and a real blind screen-reader user on every engagement. Pick your pages. We bring the humans.
Worth Reading Next
Related on this site
Guides, checklists, tools, and terms that go with this service.