Methodology — what "verified" means here

The accessibility industry has a trust problem: scanners overstate what they can find, and overlay widgets overstate what they can fix. Our answer is to show our work on every single finding.

The 30–40% problem

Research from multiple independent teams converges on the same number: automated tools can detect roughly 30–40% of WCAG issues^[1]. The remainder — keyboard operability, meaningful labels, sensible focus order, whether the alt text actually says something useful — needs execution and judgment. An audit that stops at a scan report leaves the majority of barriers (and the majority of legal exposure) untouched.

Candidates, not conclusions

We treat automated results as candidates only. Every candidate is independently re-executed with a targeted check, and gets exactly one of three statuses:

Verified

Our own re-execution confirms the failure. The finding carries a verification stamp: the method used, the timestamp, and evidence (screenshot, measured values). Example: a contrast candidate is recomputed from the rendered styles with the WCAG luminance formula — the stamp shows "2.81:1 measured, 4.5:1 required".

Not reproduced

Our re-execution contradicts the candidate. It does not appear in your issue log as a defect — it appears on a transparency sheet, because you deserve to see what we ruled out and why.

Needs human

The question requires assistive-technology or expert judgment (screen-reader nuance, content sense). These are tested manually with NVDA and marked expert-reviewed only after that review actually happens — never by default.

How re-execution works

• Accessible-name re-inspection — every name source (labels, alt text, ARIA attributes, text content) re-read from the live page, independently of the scanner's engine.
• Contrast recomputation — foreground/background resolved from rendered styles, composited through transparency, measured with the WCAG relative-luminance formula.
• Keyboard tab-walk — we actually press Tab through your page and record where focus goes, where it can't go, and where it gets stuck.
• Focus-visibility pixel comparison — screenshots with and without focus, compared byte-for-byte. If nothing changes on screen, keyboard users are navigating blind.
• ARIA re-checks — roles, states, and ID references validated against the ARIA specification and the live DOM.

Checks scanners don't run at all

Three of our standard checks have no scanner equivalent, because they require behaving like a user rather than parsing markup: keyboard traps (can Tab leave every component?), invisible focus (is there any visual indicator at all?), and mouse-only controls (elements that announce themselves as buttons but can never receive keyboard focus). These are consistently among the most serious barriers we find.

What we don't do

• We don't guarantee or certify legal compliance — nobody honestly can, and the FTC fined an overlay vendor $1M for claims in that direction^[3]. We provide technical evidence and remediation guidance; your attorney owns legal strategy.
• We don't sell or install overlay widgets. Ever.
• We don't scan-and-run: raw scanner output without verification is not a deliverable here.
• We don't test what we can't reach: audits cover a representative page sample at a point in time. Sites change — that's what monitoring (re-verification) is for.

Sources

Every statistic we use in marketing or reports, with its origin. Figures are re-checked quarterly; if a number ages out, we pull the claim.

1. Automated-scanner coverage ~30–40%: Accessible.org analysis; Deque's own coverage report shows automated findings for 16 of 50 WCAG 2.1 AA criteria.
2. 2025 US ADA website lawsuit filings (3,948; +23.8% YoY; 983 widget-equipped sites sued): EcomBack annual report.
3. FTC order against accessiBe ($1M, final April 2025): FTC press release.
4. European Accessibility Act enforceable 28 June 2025: Bird & Bird briefing.