What a journey measures

A journey audit is measured once per step, at the end of the step. That single rule decides whether a journey finds the problem you were looking for. A journey written as one step called “log in and check out” produces exactly one measurement — of the confirmation page — and reports nothing about the login form, the cart, or the payment screen it passed through on the way.

This page is the full model. If you only remember one thing, remember that the steps you write are the states that get checked.

One measurement per step boundary

For each step, the browser does this and only this:

Settles the page, then runs the accessibility engine — the entry snapshot.
Performs the step’s actions, in order.
Settles again, then runs the engine a second time — the exit snapshot.
Reports exit − entry, plus what the transition detectors saw across the boundary, plus a probe pass.

Nothing runs the engine inside step 2. A step with one action and a step with fifteen actions each produce one measurement. Every state the page passed through between the first and last action is invisible to the audit.

A step whose first action navigates (Go to URL) snapshots immediately after arriving instead of before, because the arrival state is that step’s entry state.

The practical consequence: split a flow at every state you want checked. Three steps of two actions cover three states; one step of six actions covers one.

Each step reports only what it introduced

Subtracting the entry snapshot from the exit snapshot means a step raises only the violations that were not already on the page when the step began. Pre-existing problems belong to the page scan that covers that URL, not to the journey — otherwise every step would re-report the site’s header and footer.

Two exceptions, both deliberate:

An arrival onto a page no scan covers reports its whole entry state. If a step navigates to a URL that is not in the site’s scanned pages, nothing else would ever report it, so the journey emits the arrival state in full rather than only the delta.
If a step cannot take its entry snapshot, the step fails. It does not fall back to an empty baseline, because an empty baseline subtracts nothing and would re-report every load-time violation as though the step had caused it.

How findings are attributed

Attribution is not uniform, and the difference matters when you are citing a step in an audit.

Source	Attribution	Precision
Accessibility engine (axe)	`exit − entry` per step	Exact — the step introduced it
Transition detectors	The step whose boundary they observed	Exact
Probes	First sighting within the run	Approximate

Probe findings are run-level first-sighting: a probe result is recorded against the first step that saw it, keyed by URL plus rule plus element. That step is where the problem was first observed, not necessarily the step that caused it — a focus trap present on page load will be attributed to whichever step first interacted with that page. Treat a probe finding as “seen from here”, not “introduced here”.

The probes that run on each step are positive tabindex, focus order, enhanced target size, autoplaying media, missing visible focus, and focus traps — intersected with the probes your site has enabled. Journeys never turn on a probe your site config has off.

The transition detectors

Six checks watch the boundary between a step’s entry and exit state:

Check	WCAG	Fires when
Focus lost	2.4.3	Something had focus, and nothing does afterwards
Focus orphaned	2.4.3	The focused element was removed from the page
Focus not moved to revealed content	2.4.3	A dialog appeared and focus stayed outside it
Status message not announced	4.1.3	Content changed with no focus move and no live-region update
Change of context on input	3.2.2	Filling a field changed the context
Change of context on focus	3.2.1	Moving focus changed the context

Two limits worth knowing. “Status message not announced” needs a live region to have existed at entry — a page with no live region at all can never produce this finding. And the two change-of-context checks only fire when the whole step is homogeneous (all fills, or all focus-movement keys); a step that clicks and then fills reports neither, because nothing could say which action moved the user.

Error messages (3.3.3)

If AI Deep Audit is on for the site, each step’s reached state is also checked for Error Suggestion (WCAG 3.3.3): when a form rejects what you typed, does the message tell you how to fix it?

This is a check a page scan cannot perform at all. A scan never submits a form, so the only error text it can ever see is whatever the page happened to render on load. A journey submits forms by construction, and the state after a failed submit is exactly what the criterion is about.

Three things to know about it:

It is advisory. The model is judging wording, so the finding is flagged for a human to confirm and never feeds the compliance percentage — the same treatment every AI Deep Audit finding gets.
It is cheap by design. Nothing is sent to a model unless the reached state actually contains an error message. A journey that never trips a validation error costs nothing extra, and a run is capped at four judgments no matter how many messages appear.
It follows the same attribution rules as everything else on this page: the finding belongs to the step that reached the state, and a message seen at three consecutive steps is reported once, against the first.

Turn it off with the site’s AI Deep Audit setting, which controls this and the post-scan pass together.

The mobile pass

When a run reaches the end, one final pass checks reflow and mobile target size at a mobile viewport. It runs once per run, not per step, and its findings are recorded against the last completed step.

A run that gets blocked never reaches this pass, so a blocked run has no mobile-viewport coverage at all.

What a blocked run does not tell you

A run stops at the first step that cannot complete. Everything after that point is unmeasured, and the run detail says so explicitly (“Steps 4–6 were not measured”).

The blocking step is measured zero times, not once. Its exit snapshot is never reached, so it reports no findings — only a status, a detail message, and a screenshot of the stuck state.
Steps that completed before the blockage keep their findings. A partial run is real evidence for the part that ran.
Issues from steps that never ran are left untouched. A journey cannot resolve an issue by failing to reach it — absence of evidence is not evidence of a fix.

What journeys do not change

Journey findings become scored issues, tagged with the WCAG criteria they fail — with the single exception of the AI error-message check above, which stays advisory. They get the full issue workflow: assignment, comments, tracker sync, and automatic resolution when a later run of the same step stops reproducing them. They appear in the issue queue, site analytics, exports and the VPAT.

They do not move the compliance percentage. That number is computed only from full-page scan results, exactly like interaction scenarios. Journeys widen what the issue queue can see; they do not re-score the site.

Agentic journeys measure less

In agentic mode a step carries a goal instead of actions, and the model picks the actions on each run. Because the chosen actions are performed before any snapshot is taken, the entry and exit snapshots are both of the final state — so the exit − entry delta is empty and the transition detectors have no boundary to observe.

An agentic step reports probe findings only. If per-step engine findings matter to your audit, write the journey in scripted mode.

Writing steps for the coverage you want

One step per state you want checked. “Open the cart” and “Fill delivery details” are two steps, not one.
The editor tells you what your draft will measure as you write it, and flags any step that commits more than one page state.
Steps are cheap. Twelve steps is the maximum; a flow worth auditing usually wants five or six.
Give steps labels you would be happy to read in an audit report — they name the measured states everywhere in the product.