What is journey-based accessibility testing?
Journey-based accessibility testing checks whether someone using assistive technology can complete a whole task on your site — sign up, search, check out — rather than whether each page, taken alone, breaks a rule. It attempts the task the way a keyboard and screen-reader user would, and reports whether the task could be finished and the exact step where it could not.
Why test journeys instead of pages
People do not visit a website to look at pages. They come to do something, and an accessibility failure matters most when it stops them doing it. A missing label on a newsletter footer and a missing label on the card number field are the same rule violation; only one of them ends a purchase.
Page-level testing cannot tell those apart, because it has no idea what the page is for or what comes next. A journey does. It carries the goal from the first step to the last, so a barrier is reported in terms of what it blocked — and every step after an unrecoverable break is reported as not reached, not as passed.
How it differs from a static scan
A static scan loads a page and runs automated rules against its markup: missing alternative text, low contrast, inputs without names, invalid ARIA. It is fast and belongs on every page, but it sees one state — the page as it loaded — and it checks whether things are present, not whether they work.
A journey acts, then checks what happened. After each click or keystroke it asks the questions a screen-reader user would: what was announced, where focus landed, whether a status message was spoken, whether the form still makes sense. Those are exactly the failures a scan cannot reach — focus that stays behind an opened dialog, a silent “added to cart”, errors that appear only after submitting. The gap is large enough that when the UK Government Digital Service ran ten automated tools against a page with 143 deliberate failures, 29% were missed by every tool (UK Government Digital Service, 2017). Why automated scans miss real accessibility issues covers that gap in detail.
How it differs from a manual audit
A manual audit by an accessibility specialist is the most thorough evaluation available. An auditor judges what no automated process can: whether alternative text describes the image, whether instructions make sense, whether a flow is reasonable rather than merely possible. The W3C is explicit that evaluation tools “can not determine accessibility, they can only assist in doing so” (W3C Web Accessibility Initiative, 2024).
What an audit is not, for most teams, is frequent. It samples pages and flows at a point in time, and the site keeps shipping afterwards. Automated journey testing trades some of the auditor's judgment for repeatability: the same critical tasks, attempted on every release, with a record of when each one last worked. The two are complementary — journeys catch the regression the week it ships; audits catch what only a person can.
| Static scan | Journey test | Manual audit | |
|---|---|---|---|
| Unit of testing | One page | One task, across pages | A sample of pages and flows |
| Who performs it | A rule engine | A simulated screen-reader user | An accessibility specialist |
| What it reports | Rule violations per page | Whether the task finished, and the step it broke on | Findings against WCAG, with expert judgment |
| Judges meaning and quality | No | Partly — what was announced, in context | Yes |
| Repeatable every release | Yes | Yes | Rarely, because of cost and time |
What a journey actually contains
A journey is a task written down precisely enough to be attempted the same way every time. It has five parts:
- Goal
- What the user is trying to get done, in plain language: "Buy one product as a guest", "Reset a forgotten password".
- Start URL
- Where the attempt begins — usually the page a real visitor would land on, not a deep link that skips the hard part.
- Steps
- The sequence the task passes through: find the product, add it to the cart, open the cart, enter an address, pay.
- Success criteria
- How you know the goal was reached — an order confirmation, a signed-in dashboard, a submitted form.
- Test data
- The values the task needs: a test account, a search term, a shipping address, a test card number. Never live credentials.
Examples
- Guest checkout: from a product page, add an item, open the cart, enter shipping details, pay with a test card, reach the confirmation.
- Sign-up: from the home page, open the sign-up form, submit it with one field wrong, recover from the error, and reach the account.
- Search and filter: search for a term, apply a filter, and open a result — checking that the results update is announced.
- Password reset: request a reset, follow the flow, and confirm the new password is accepted.
Deliberately include a mistake in at least one journey. Error recovery is where forms most often fail screen-reader users, and a journey that only ever enters perfect data never sees it.
What a journey test reports
A useful result is a ledger of the attempt, not a score. For each step it records what happened; for each barrier, the WCAG success criterion it fails, how severe it is, which steps it affected, and the fix. When the task stops, the steps it never reached are marked as not evaluated, so a blocked journey cannot be misread as a mostly passing one.
In Accessible, journey testing runs this way in a real browser with a simulated screen-reader user. Discovery proposes the journeys worth testing, and each one can run on demand, on deploy or on a schedule.
Sources
- What we found when we tested tools on the world’s least-accessible webpage (opens in a new tab). UK Government Digital Service, February 24, 2017. Independent. One deliberately inaccessible test page, 143 failures, 10 tools.
- Selecting Web Accessibility Evaluation Tools (opens in a new tab). W3C Web Accessibility Initiative, May 13, 2024.