What are the three layers of accessibility testing?

Static scans, which check each page’s markup against automated rules; simulated journeys, which attempt real tasks the way a keyboard and screen-reader user would; and real user monitoring, which checks for barriers inside real visitors’ sessions. Each catches failures the others miss.

What is the difference between synthetic and real user accessibility testing?

Synthetic testing — scans and scripted journeys — runs in a browser you control, on pages and paths you choose. Real user monitoring runs in your visitors’ browsers on whatever they actually loaded. It is the same distinction web performance teams draw between lab data and field data.

Do I need all three layers?

For a site where people must complete tasks, yes. A scan alone cannot tell you a checkout works; a journey only covers the paths you scripted; monitoring cannot tell you whether a task is completable. Together they cover every page, every critical task, and every real session.

Do automated layers replace manual accessibility testing?

No. Periodic testing by experienced assistive-technology users is still the benchmark for judgments automation cannot make, such as whether content is understandable or a flow is reasonable. Automated layers make that testing rarer and more targeted, not unnecessary.

Static Scans vs. Simulated Journeys vs. Real User Monitoring

What is the difference between them?

A static scan checks whether a page breaks automated rules. A simulated journey checks whether a screen-reader user can complete a task. Real user monitoring checks which barriers real visitors actually hit. The first covers every page, the second covers the tasks that matter, and the third covers everything that happens in production.

The three layers

Layer 1

Static scans

A static scan loads a page and runs rules against its markup and styles — does this image have alternative text, does this text meet the contrast ratio, is this input named. It is fast, deterministic and cheap enough to run on every page, every release.

Automated scanning in Accessible

Layer 2

Simulated journeys

A simulated journey attempts a task — sign up, search, check out — the way a keyboard and screen-reader user would, step by step, checking what is announced and where focus lands after each action. It answers whether the task can be completed, and where it stops.

Journey testing in Accessible

Layer 3

Real user monitoring

Real user monitoring runs accessibility checks inside real visitors’ sessions and reports which barriers they met, and how often. It sees the states, content and conditions people actually had, including the ones nobody thought to test.

Real user monitoring in Accessible

What each layer catches and misses

Comparison of static scans, simulated journeys and real user monitoring
	Static scans	Simulated journeys	Real user monitoring
Question it answers	Which rules does this page break?	Can this task be completed, and where does it stop?	Which barriers did real visitors hit, and how often?
What it tests	A page, as it loaded	A task, across pages and states	Real sessions, as they happened
Where it runs	A browser you control	A browser you control	Your visitors’ browsers
When it runs	On a schedule or on deploy	On demand, on deploy, or on a schedule	Continuously, on sampled sessions
Catches well	Missing names and alternative text, low contrast, invalid ARIA, missing language	Focus not moving into dialogs, unannounced status messages, form errors after submit, the step a task breaks	States no script reaches, third-party and personalized content, focus traps and lost focus in real use
Misses	Anything after an interaction; whether names are meaningful; whether a task can be finished	Paths and content variations you did not script; what real visitors actually encounter	Whether a task can be completed; pages nobody visits; anything before the code ships
Best used for	Coverage of every page and catching regressions	Proving the critical tasks work before release	Prioritizing by real impact and finding what testing missed

The lab-and-field split, borrowed from performance

Web performance settled this argument years ago. Lab data comes from loading a page in a controlled environment with predefined conditions; field data comes from monitoring the people who actually visit — and web.dev notes that field data is also commonly known as Real User Monitoring (web.dev, 2022). Performance teams use both, because a page that is fast in the lab can still be slow for real visitors on real devices.

Accessibility has the same split. Static scans and simulated journeys are lab tests: controlled, repeatable, and limited to what you chose to test. Real user monitoring is the field: uncontrolled and complete, but only after the code ships. The split is covered in depth in real user monitoring vs. synthetic testing.

Why you need all three

Each layer's blind spot is another layer's strength.

Scans alone report a clean page while a dialog traps focus or a checkout cannot be finished — see why sites pass axe-core but fail real screen-reader users.
Journeys alone prove the paths you scripted, in the state you set up, and nothing else.
Monitoring alone tells you where real visitors struggle, but only after they have, and cannot say whether a task is completable.

Run together, scans keep every page honest, journeys protect the tasks that make money or matter most, and monitoring catches what both missed and tells you which fix helps the most people first.

None of the three replaces testing by people. The W3C's position is that evaluation tools “can not determine accessibility, they can only assist in doing so” ( W3C Web Accessibility Initiative, 2024). Automated layers make manual review rarer and better aimed.

Sources

Why lab and field data can be different (and what to do about it) (opens in a new tab). web.dev, July 18, 2022.
Selecting Web Accessibility Evaluation Tools (opens in a new tab). W3C Web Accessibility Initiative, May 13, 2024.

Static scans vs. simulated journeys vs. real user monitoring