Assistive technology testing is conducted
Why it matters
Automated tools catch roughly 30–40% of WCAG failures. The remainder — focus management, ARIA live region behavior, reading order, screen reader announcement timing — only surface during testing with real assistive technology. Without documented screen reader testing, an app can pass all automated checks and still fail VoiceOver on Safari or NVDA on Chrome in ways that make core features unusable. For any product claiming WCAG compliance or seeking Section 508 contracts, AT testing evidence is a prerequisite.
Severity rationale
Info because the absence of AT testing is a process gap rather than a direct failure of any single WCAG criterion — but it means the remaining ~60% of potential violations go undetected and the compliance claim cannot be substantiated.
Remediation
Create a documented AT test plan and record results in docs/accessibility-testing.md at the repo root.
# Accessibility Testing Log
## Test combinations
- NVDA 2024.1 + Chrome 123 (Windows)
- VoiceOver + Safari (macOS)
- VoiceOver + Safari (iOS)
## Tested routes
- [ ] / (homepage)
- [ ] /login
- [ ] /dashboard
- [ ] Main user workflow: create → review → submit
## Last tested
2026-04-01 — no critical issues found
Minimum: test the critical user path (sign up, core feature, billing) with VoiceOver + Safari and NVDA + Chrome. File tickets for any issues found. Re-test after major UI changes.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Accessibility WCAG Compliance Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- wcag:2.2 · 1.1.1 — Non-text Content
- section-508:2018-refresh · 501.1 — Scope
Taxons
History
- 2026-04-18·v1.0.0·Initial import from accessibility-wcag·automated