Method
How we test
Automated scanning, manual expert review, and assistive-technology testing, kept separate and never blended into one number. Most accessibility vendors won’t show you this breakdown.
What automated tooling catches
A measured floor, not the whole test
axe-core, run via Playwright across every authenticated state, modal, error state, and interactive component your users actually hit — not just the logged-out homepage. This is real coverage, and it’s where every engagement starts. It is not where any engagement ends.
Automated tooling floor is a measured, cited figure. Deque, automated accessibility coverage report. The hatched remainder is not broken down by percentage in this diagram, because no source supports that precision — it is closed by manual expert review and assistive-technology testing, described below.
What it cannot determine
The part a scanner cannot see
- Whether alt text is correct — a scanner confirms an attribute exists, not that it says something useful.
- Whether focus order makes sense to a person actually navigating the page.
- Whether a real task can be completed — booking an appointment, submitting a form, recovering from an error.
- Whether a state change (a live region, a loading state, an optimistic update) is ever actually announced.
- Whether a component that looks fine on inspection sounds like a bare number when a screen reader reaches it — the exact failure mode Cal.diy's date picker had, and axe reported zero violations for both before and after.
How the gap gets closed
Four methods, run in order, never merged into one report
- Automatedaxe-core, every state — the 57% floor above.
- Manual expert reviewFocus order, semantics, and error handling read by a person, not a rule engine.
- Assistive technologyNamed screen reader, browser, OS, version — task completion, not spot checks.
- VerificationA dated conformance statement with named scope, plus a CI gate so it doesn’t decay.
Assistive technology we test with
Named versions, recorded — not implied
Windows
NVDA + Chrome and Firefox.
macOS / iOS
VoiceOver + Safari.
Every platform
Keyboard-only: no mouse, full task completion required.
Screen reader and browser versions are named in every evidence pack. A finding that says “tested with a screen reader” with no version recorded is not a finding this studio produces.
What our conformance statements claim
“Conforms to WCAG 2.2 Level AA for [named scope], as tested on [date], by [methods].” Every statement carries a scope and a date. A conformance statement without both is a marketing claim.
What we never say
- "ADA compliant" / "ADA compliance guaranteed"
- "100% accessible" / "fully accessible"
- "lawsuit-proof" / "protects you from litigation"
- "compliant in 48 hours" / any automated-compliance promise
- "certified accessible" (we are not a certifying body)
- anything about WCAG 3.0 readiness
Why this method exists
The industry-wide numbers this responds to
95.9%
of top home pages had detected WCAG failures in February 2026 — up from 94.8%, the first regression in six years.
WebAIM Million ↗56.1
errors per page on average, up 10.1%, as page complexity rose 22.5% in one year.
WebAIM Million ↗25.55%
of Q1 2026 ADA web filings targeted sites that already had an accessibility widget installed.
EcomBack ↗