Webscan Documentation
Lesson 13 · User journeys
Phase 3 · Beyond the public page — Lesson 13 of 21 · All lessons
Objective: understand what a journey is, build one step by step, run it, and read the results — so you can scan a specific multi-step flow exactly the way real users move through it.
Before you start: a website (Lesson 3). A scan profile (Lesson 11) is useful if the flow needs a login.
What is a journey?
Journey — a scripted, repeatable sequence of steps through your site that you author yourself, with an accessibility scan run along the way. Where agentic exploration lets webscan decide the path, a journey is one you define precisely: "go here, click this, type that, then scan."
Journeys shine for the flows that matter most to your users and that you want to check the same way every time — a checkout, a sign-up, a booking, a support-ticket form. Because a journey is fixed, running it repeatedly gives you a consistent, comparable result each time.
The building blocks
A journey is made of ordered steps. Each step performs one action:
| Action | What it does |
|---|---|
| Navigate | Go to a URL. |
| Click | Click an element (needs a selector). |
| Type | Type text into a field (needs a selector and a value). |
| Select option | Choose from a dropdown (needs a selector and a value). |
| Wait for element | Pause until an element appears (needs a selector). |
| Assert visible text | Check that expected text is present — a checkpoint that the flow worked. |
| Run accessibility scan | Scan the current page for barriers. |
Two supporting ideas:
- Selector — a CSS selector identifying the element a step acts on (e.g.
#submit,.cart-button). The same idea you met in findings (Lesson 5). - Scan after — a per-step toggle: after this step runs, scan the resulting page. This is how a journey collects findings at each stage of the flow, not just at the end.
Build a journey
- From the website page, open User journeys and create a new journey with a name and optional description. If the flow is behind a login, attach a scan profile so the journey runs authenticated.
- On the journey page, use Add step to add each action in order. For each step set its action, selector/value as needed, and whether to scan after.
- Repeat until the journey mirrors the real flow — e.g. Navigate to /shop → Click a product → Click "Add to cart" → Navigate to /checkout → Assert "Order summary", scanning after the key pages.
Safe mode: safety levels and restricted actions
A journey can act on your site, so — like exploration — it has guardrails. Every step carries a safety level:
| Safety level | Meaning |
|---|---|
| Safe | Ordinary, non-damaging (navigating, scanning, reading). |
| Restricted | Could change data or state (submitting a form, changing a setting). |
| Destructive / irreversible | Could delete or permanently alter something. |
By default a journey runs in safe mode: it will skip restricted and destructive steps unless you explicitly turn on allow restricted actions for that journey. And as a hard rule, restricted actions can't be enabled on a production website at all — that's the blast-radius protection from Lesson 1.
If a run comes back Blocked by safe mode, it means the journey hit a restricted/destructive step that the current settings don't permit — the guardrail working as intended.
Run it and read the results
Choose Run journey. Webscan queues a run and executes the steps in order; you can watch the run's status move Queued → Running → Completed (or Failed, or Blocked by safe mode). Open a run to see, step by step:
- whether each step Passed, Failed, or was Blocked,
- the page it was on,
- and the findings (violation and review counts) from any scan-after step.
Those findings are ordinary findings — they flow into verdicts and issues just like everything else.
Journeys vs. exploration — which to use?
- Use a journey when you know the exact flow and want a repeatable, consistent check of it (regression-style).
- Use agentic exploration when you want webscan to discover a path or probe by intent.
They're complementary: explore to find what matters, then codify the important flow as a journey you run again and again.
Tips & pitfalls
- Add "Assert visible text" checkpoints. They catch a flow that silently broke (e.g. a step didn't actually reach the next page) instead of scanning the wrong page.
- Turn on "scan after" at the stages that matter, not every step — it keeps runs fast and findings focused.
- Get selectors right. A brittle selector is the usual reason a step fails; copy a stable one from the page's HTML.
- Never expect restricted steps to run on production — they're blocked by design. Test those flows on staging.
Recap
- A journey is a you-authored, repeatable multi-step flow with scans along the way — the counterpart to agentic exploration.
- Steps use actions (Navigate, Click, Type, Select, Wait, Assert, Scan) with selectors and a scan after toggle.
- Safe mode skips restricted/destructive steps unless allowed — and never in production.
- Runs report per-step Passed/Failed/Blocked plus findings that flow into the usual workflow.
Try it yourself
Build a short journey for an important flow on your site (three or four steps), turn on scan after for the key page, and run it. Open the run and confirm each step's result, then take one finding through to a verdict.
Previous: ← Lesson 12 · Agentic exploration Next: Lesson 14 · Manual audits →