Accessibility testing: scope a complete user journey

Start with an outcome, not a page count

A useful starting brief might say: an employee can request an equipment replacement, understand missing information, correct it and find the resulting request status. That gives the team something concrete to examine. A brief saying test five pages does not explain whether the task crosses an untested dialog or third-party sign-in step.

Choose one important journey for an initial planning exercise, then document what remains outside it. This is a way to make a brief manageable, not a method for declaring the whole product accessible. The evaluation lead should determine how that journey fits into a wider representative assessment.

• Identify the intended users and the work they are trying to complete.
• Write the start condition, successful end condition and how the person knows they have finished.
• List connected systems, documents and embedded components rather than stopping at your own application boundary.

Include the states a screenshot does not show

The same page may behave differently after an error, a session expiry or a delayed response. Ask the team to walk through these states in a safe test environment using fictional records. Record where the user must notice a change, make a decision or recover from a mistake.

In our hypothetical equipment-request journey, selecting an item is only the beginning. A required-field error, an unavailable item, a confirmation dialog and the final status all belong in the brief. These are proposed planning examples, not findings about a customer product.

• Empty, loading and unavailable states: what does the person learn and what can they do next?
• Validation and recovery: can the person locate the problem and continue without losing necessary work?
• Dialogs and handoffs: what changes when a panel opens, closes or sends the person to another service?
• Completion: distinguish a request received from a request approved or fulfilled.

Give each evaluation method a clear job

Use automated checks for repeatable signals within their supported rules. Ask knowledgeable people to investigate interaction and meaning, including keyboard use, assistive technology and presentation changes relevant to the agreed environments. Neither a clean tool report nor one successful demonstration should become a blanket accessibility statement.

Research with people with disabilities adds evidence about actual task use. Plan participation with appropriate research support, accessible materials and clear consent. WAI cautions against treating one participant's experience as representative of everyone. Keep user-research findings and standards evaluation connected, but do not describe them as interchangeable.

• Automated checks: identify the tool, rules, build and captured states; investigate findings rather than treating every flag as confirmed.
• Manual evaluation: name the evaluator, methods and browser or assistive-technology combinations actually examined.
• Participant research: record the task and study boundaries, without publishing identifying participant information.

Use a six-field journey brief

Use these six fields to prepare a conversation with your product, design, engineering and evaluation leads. The worksheet organises work; it is not a substitute for an accessibility evaluation methodology. Attach unknowns instead of filling them with assumptions.

• Task and boundary: who is doing what, where it starts, what completion means and which dependencies are included.
• States and sample data: the normal path, errors, recovery, interruptions and fictional records needed to reproduce them.
• Evaluation basis: the standard and version the responsible evaluator selects, plus what this limited exercise cannot establish.
• Environment and methods: the devices, browsers, assistive technologies, manual work, automated checks and user research actually planned.
• Evidence and ownership: expected behaviour, observed barrier, reproducible steps, relevant criterion where assessed, responsible team and target build.
• Retest and decision: who checks the fix, which connected states are revisited and who records unresolved release limitations.

Fix the barrier, then revisit the task

Suppose the fictional request form displays an error, but a person using the agreed test setup cannot discover which input needs attention. A useful finding records the build, steps, observed behaviour and effect on completing the task. The implementation team and evaluator can then agree a fix and a reproducible retest.

After that fix, revisit the connected journey, not only the edited component in isolation. Record whether the person can continue, submit and understand the result. When a shared component changes, identify other usages that need review. Do not close the issue merely because the original scan warning disappeared.

• Separate a proposed fix from an implemented fix and a verified outcome.
• Keep the tested build and environment with the result so later teams can reproduce it.
• Carry unresolved barriers and untested areas into the release discussion with explicit owners.

Understand the trade-off in a narrow first scope

A focused journey makes responsibilities and evidence easier to discuss, but leaves other tasks unexamined. A broad page inventory covers more surfaces, but can still miss interactions between them. Plan both deliberately: a wider assessment should not become a pile of disconnected screenshots, and an initial journey should not become the entire accessibility programme.

Third-party widgets, documents and authentication can also affect completion. If you cannot change them directly, name the dependency owner and agree how findings and retests will be handled. An exclusion in your test plan does not remove the barrier experienced by the person using the product.

Bring a usable brief to product planning

Before asking for an estimate, bring the selected task, current design or safe prototype, known dependencies and the six-field brief. Identify which decisions require accessibility expertise or other qualified advice. Keep claims proportionate to the evidence: examined this journey on this build is different from independently assessed the entire product.

Codersbay Technologies' digital product engineering offering brings product strategy, experience design, engineering and quality work together. Use the enquiry link to discuss how journey-level evaluation fits your product scope, and clarify any specialist evaluation needs separately. No particular certification, packaged audit or business outcome is promised by this guide.

Frequently asked questions