Assistive-tech compatibility testing
assistive-tech-compatibility-testingDomain: accessibilityType: processDescription
Assistive-technology compatibility testing is the part of the accessibility program where abstract WCAG conformance claims meet the reality of users driving the product with NVDA, JAWS, VoiceOver, TalkBack, magnifiers, and switch-control input. Automated accessibility scanners catch roughly 30 to 40 percent of issues against the WCAG criteria they test for (the figure is widely cited in the accessibility engineering literature, with axe-core, WAVE, and Lighthouse converging on roughly that detection rate against curated benchmarks); the remaining majority surface only when a real assistive-technology stack interacts with the product. A working compatibility-testing program decomposes into four layers. The matrix of supported assistive technology names the specific AT and version coverage (typically the two leading screen readers per platform: NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android, plus zoom-magnification and switch-control input where the product reaches users dependent on those modalities). The test cadence anchors when tests run: each release for changed surfaces is the minimum, with a full sweep on a longer cycle (quarterly is common, with the regulation-mandated WCAG 2.2 AA review cadence being the floor rather than the ceiling). The documentation layer captures compatible versions and the known-issue list, with the known-issue list serving double duty as input to the public accessibility statement so the statement's named limitations field stays current with what testing actually surfaces. The regression-test integration catches new breakage before release rather than after; this is the load-bearing piece because AT compatibility is genuinely fragile against framework upgrades and design-system changes (a passing test on the current React or Tailwind version is not a guarantee that the same flow passes after the next major upgrade, and aria-attribute handling has historically been the area where regressions hide longest). The statutory anchors that drive AT-compatibility expectations are layered. ETSI EN 301 549 V3.2.1 (2021-03) is the EU harmonized standard referenced by both the European Accessibility Act (Directive (EU) 2019/882) and the EU Web Accessibility Directive, and Clauses 5 through 13 cover AT-compatibility expectations directly; the Annex A mapping shows which clauses satisfy which WCAG 2.1 success criteria. US Section 508 (29 U.S.C. §794d) via the Section 508 Refresh adopts WCAG 2.0 AA by reference; DOJ's 2024 Title II web rule under ADA at 42 U.S.C. §§12101-12213 adopts WCAG 2.1 AA for state and local government entities. The UK Equality Act 2010 c. 15, the Accessible Canada Act S.C. 2019, c. 10, and Ontario AODA S.O. 2005, c. 11 set the parallel obligations in their respective jurisdictions. Evidence formats that satisfy a regulator inquiry include the AT-test matrix itself, a compatibility-version dashboard showing tested AT and version coverage over time, and the regression-test output integrated into the release pipeline.
Required by (5 regulations)
- ACA
Accessible Canada Act, S.C. 2019, c. 10; AODA, S.O. 2005, c. 11
- ADA
42 U.S.C. §§12101–12213
- EAA
Directive (EU) 2019/882
- EN 301 549
ETSI EN 301 549 V3.2.1 (2021-03)
- Equality Act
Equality Act 2010, c. 15
Fulfilled by (3)
- deque · partial · medium effort · $$
- In-house build · medium effort
- In-house build · partial · medium effort · $Build assistive-tech compatibility testing against the Xbox Accessibility Guidelines (published Microsoft framework + checklist).
Magist does not accept payment from vendors. Methodology.
Evidence formats
- AT test matrix
- compatibility-version dashboard