Screen Reader Simulation for Real User Journeys
Name a task — sign up, search, check out. A simulated screen-reader user drives a real browser through it and reports the exact step it could not get past, with what was announced there as evidence.
- Passed. 1 · Sign-in form — labels announced
- Passed. 2 · Submit — error summary takes focus
- Passed. 3 · Dashboard — heading level 1 announced
- Serious. 4 · Search field — placeholder, no label
- Critical. 5 · Results — list replaced silently
- Not evaluated. 6–7 · not reached
Completed 3 of 7 stepsWCAG 4.1.3 · 3.3.2
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
What is journey-based accessibility testing?
Journey-based accessibility testing checks whether someone using assistive technology can complete a whole task on your site, rather than whether each page breaks a rule. It attempts the task the way a blind screen-reader user would — moving by headings, landmarks and tab order, listening to what each control announces — and reports the step where the task could not continue.
How a journey run works
Explore
The run opens the starting page and maps it the way a screen-reader user first meets it: headings, landmarks, skip links, live regions, forms, and an axe-core baseline of rule failures already present.
Execute
It works through the journey one step at a time, keyboard only, moving by heading, landmark, role and tab order. After every click or keystroke it checks what was announced, where focus landed, whether a status message was spoken, and whether the form still makes sense.
Assess
A final pass writes the report: whether the goal was reached, each barrier classified against a WCAG 2.2 success criterion with a severity, the steps it affected, and the fix. Steps after the break are marked not evaluated — never passed.
- Passed. Tab 1
- “banner landmark, Accessible, link”
- Passed. Tab 2
- “main landmark, heading level 1, Checkout”
- Passed. Tab 3
- “Shipping address, edit, required”
- Critical. Tab 4
- “edit, blank”
Tabs 4 through 7 all announce “edit, blank”. Nothing distinguishes the card number from the expiry, the security code, or the postcode.
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
What a journey catches that a static scan cannot
Every one of these can sit on a page with no rule violation at all. They only show up when something tries to use the page.
Focus that goes nowhere
A cart drawer or dialog opens, and focus stays behind it — or lands back on the page body. A scan of the page sees valid markup; a keyboard user is lost.
WCAG 2.4.3
Status messages nobody hears
"Added to cart", an error summary, a results count: text that appears without a live region is silent to a screen reader. Only something that acts and then listens can notice.
WCAG 4.1.3
Forms that cannot be told apart
Four inputs that each announce "edit, blank", errors that appear visually but are never associated with the field, and messages that say something failed without saying what to do.
WCAG 3.3.1 · 3.3.2 · 4.1.2
Controls the keyboard cannot reach
A clickable div, a menu that only opens on hover, a focus indicator that disappears. The journey tries to operate each control the way the task needs, not just list it.
WCAG 2.1.1 · 2.4.7
Content that only exists after you act
Menus, accordions, modals, filtered results and the next page of a multi-step form. A scan checks the page it loaded; a journey checks the states the task actually passes through.
WCAG 1.3.1 · 4.1.2
Example: a guest checkout that ends at payment
This nine-step run comes from a test storefront, not a customer site. The task was to buy one product as a guest — the ledger beside this is the run it produced.
- Step 1, product page: announced correctly.
- Step 2, add to cart: a live region confirms the item was added.
- Step 3, cart drawer: the drawer opens but focus does not move into it — a serious barrier, though the journey can continue.
- Steps 4–5, checkout and address: passed.
- Step 6, payment: the card number, expiry, security code and postcode each announce “edit, blank”. Nothing tells them apart, so the purchase cannot be completed.
- Steps 7–9: not reached, and reported that way rather than as passed.
The report files the payment step as a critical barrier against WCAG 4.1.2 (Name, Role, Value) and 3.3.2 (Labels or Instructions), with the markup change that fixes it. A page-by-page scan would have reported a missing label on the payment page — without saying that it was the one thing standing between a blind customer and the order.
- Passed. 1 · Product page — announced correctly
- Passed. 2 · Add to cart — live region confirmed
- Serious. 3 · Cart drawer — focus not moved
- Passed. 4–5 · Checkout & address
- Critical. 6 · Payment — journey ends here
- Not evaluated. 7–9 · not reached
Critical. 6 · Payment — card, expiry, security code, postcode
“edit, blank” × 4card number input has no accessible name
Completed 5 of 9 stepsWCAG 4.1.2 · 3.3.2
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
Where journeys matter most
The flows where one unannounced field or one lost focus ends the task.
Checkout accessibility
The flow where a single unlabeled field ends the sale: payment fields that cannot be told apart, guest-checkout dialogs that never take focus, and totals that update silently.
Testing checkoutForm accessibility
Labels, validation and errors, tested after a real submit — including the errors that appear on screen but are never announced or tied to the field they belong to.
Testing formsSingle-page apps
Route changes and dynamic content a scan of the first load never sees: focus dropped to the page body, and results replaced with no status message.
Testing single-page apps
Related reading: what journey-based accessibility testing is, how to test with a screen reader by hand, why sites pass axe-core but fail real screen-reader users, and the three layers of accessibility testing.
Need help fixing findings?
Accessible tells you what to fix and shows whether the fix held. If you'd like a hand with the fixing, teams on a paid plan can ask our team for remediation help, from a fix plan to the blockers on your checkout or login, scoped and quoted before anything starts.
Frequently asked questions
Does Accessible use a real screen reader like NVDA, JAWS or VoiceOver?
No. It simulates a screen-reader user in a real Chromium browser: it navigates by headings, landmarks, roles and tab order, and computes what each stop announces from the roles and accessible names the browser exposes, using axe-core. That makes a run reproducible on every release. It does not replace an occasional check by an experienced screen-reader user, which catches judgments no automation can make.
What kinds of journeys can it test?
Any task a visitor completes across one or more pages: signing up, signing in with a test account you provide, searching, filtering, adding to cart, checking out, or submitting a multi-step form. Use a dedicated test account rather than live credentials.
Do I have to write the journeys myself?
No. Discovery reads your site and proposes the journeys worth testing, which you can run as they are, edit, or replace with your own goal and steps.
How is journey testing different from an axe-core scan?
A scan checks one page’s markup against rules at the moment it loads. A journey attempts a whole task, step by step, and reports whether it could be finished and exactly where it could not — including failures that only appear after an interaction, like focus that does not move or a status message that is never announced.
How much does a journey run cost?
Journeys are the one metered part of the product. A typical run uses about 1,100 credits, every run shows its estimated cost before it starts, and your first plan starts with a trial balance.
Run a journey on the task that matters most.
Discovery proposes the journeys worth testing, every run shows its cost first, and your first plan opens with a trial balance.