阅读中文版本

Accessibility Tree Testing

Accessibility tree testing asserts against the computed semantics a screen reader receives, not the raw DOM, so tests reflect real assistive technology behaviour.

Definition

Accessibility tree testing is an approach that queries the browser-computed accessibility tree, including roles, names, and states, to verify what assistive technologies would perceive.

It is used alongside automated audits to ensure interactive components expose correct semantics and focus behaviour. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

The accessibility tree is what a screen reader actually consumes, so a button implemented as a styled div looks wrong there even when it renders correctly.

Querying by accessible role and name makes tests resilient to styling and structure changes while validating the semantics that matter.

Trade-offs and alternatives

Automated checks catch a limited class of issues, so they complement rather than replace manual keyboard and screen reader testing. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that passing an automated audit proves a page is accessible. Another is that querying by role and name is the same as querying by CSS class. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to asserting on DOM structure instead of exposed semantics and to relying only on lint-style rules and never testing keyboard flow. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include The Test Oracle Problem, Branch Coverage, Stress Testing Beyond Design Limits.