Journey audits

Per-page scanning proves pages are accessible in isolation. Journey audits prove a user can complete a task: a real browser walks your flow (sign up, search, add to cart, checkout) step by step, measures the state at the end of each step, and reports a step timeline, so the answer is “checkout blocked at step 3”, not just a violation list.

A journey is measured once per step, so the steps you write are the states that get checked. Read What a journey measures before writing one — it is the difference between a journey that finds what you were looking for and one that quietly finds nothing.

Available on Pro and Enterprise plans. Configure journeys per site under the Journeys tab; owners and admins edit and run, viewers can read results.

Anatomy of a journey

A journey has a start URL and up to 12 labeled steps. Each step is a short list of actions from the same safe set interaction scenarios use (click, fill, press key, hover, wait for element, wait), plus two journey-only actions:

• Go to URL navigates within the site (same origin only).
• Assert checks the current URL and/or that the page contains given text, so a broken flow fails loudly at the exact step instead of timing out later.

Every step that completes gets an accessibility scan of the state it reached, a screenshot, and a violation count. Actions inside a step are never scanned individually — the scan happens at the step boundary. The run ends early at the first step that cannot complete, marked “journey blocked here”; the steps after it are not measured at all.

What results mean

• A run’s outcome is completed (every step passed) or blocked at step N.
• Step findings become scored issues tagged with the journey and step, and with the WCAG criteria they fail. They get the full issue workflow (assignment, comments, tracker sync) and resolve automatically when a later run of the same step no longer reproduces them. They never change the compliance score, which is computed from full-page scans alone.
• A step reports only what it introduced — the violations already on the page when the step began belong to that page’s scan. See What a journey measures for how axe, transition and probe findings are each attributed.
• A step that was blocked or skipped keeps its issues untouched: absence of evidence is not evidence of a fix when the step never executed.

Agentic journeys

On Enterprise plans a journey can run in agentic mode: instead of exact actions, each step carries a goal (“add any product to the cart”) and on every run an AI model picks the actions from what is actually on the page. This survives redesigns that would break a scripted selector.

Guardrails, since an AI is choosing the clicks:

• The model can only pick from the same safe action set, and only target elements that exist on the page at that moment; it cannot navigate, run scripts, or invent selectors.
• At most 8 model calls per step; a step that cannot reach its goal is reported as blocked, exactly like a scripted failure. If the model returns something outside the safe action set we ask once more, and that retry counts against the same 8.
• Every run records the concrete actions the model took, so the timeline reads the same as a scripted run.
• Decisions are made deterministically where possible, but a page that changes between runs can produce different action paths. For flows that must be byte-for-byte repeatable, use scripted mode.

Running journeys

• Manually from the Journeys tab (up to 10 runs per site per day).
• Automatically after each full-site scan via the per-journey toggle. A journey with a run already queued or running is skipped, so scans can never stack runs.
• No new step starts more than 4 minutes into a run, and no single step runs longer than its own budget. A step already under way when that 4-minute mark passes is allowed to finish rather than being cut off — a half-measured step would report nothing at all — so in the worst case a run comes to rest around 7 minutes in. Exceeding a budget ends the run cleanly as blocked. These are ceilings for a pathological site: a typical run finishes in well under a minute.

Safety

Journeys perform real actions: forms get submitted, accounts can be created, orders can be placed. Treat them accordingly:

• Point journeys at a staging environment where possible.
• Never enter real payment data; journeys stop at cross-origin handoffs (payment providers) by design.
• Every journey request carries an X-TAC-Journey: 1 header so you can identify and filter this traffic in your analytics or WAF.
• Logged-in flows can reuse the site’s encrypted authenticated- scanning credentials via the journey’s “use credentials” toggle.
• Runs are never retried automatically. If the infrastructure fails mid-run, the run is marked failed and you decide whether to run it again.