Yes: begin accessibility testing by mapping the resident or patient task before anyone opens a webpage. A person may reach the right department site yet be unable to submit an application, book an appointment, report a problem, or understand the next step. The map gives a team a test scope for the handoffs, documents, identity checks, confirmation messages, and help routes required to complete the service, a practical application of the UK Government Service Manual’s guidance to understand users and their needs.
This is a field guide rather than a page-audit sequence. It pairs task mapping with testing against the Web Content Accessibility Guidelines (WCAG) 2.2, the World Wide Web Consortium standard for accessible web content. WCAG evaluates content and components; a journey map records the route a person must follow to achieve an outcome.
Build the test around the service route, not the site map
Choose one outcome that a person can describe without knowing the institution’s internal structure: request a replacement birth certificate, renew a library card, find and attend a vaccine appointment, or apply for campus housing. “Audit the admissions site” names an institutional surface. “Apply for campus housing and receive a usable next step” names the reason someone came, the result they need, and the point at which the service can fail.
A small team can map that route without a large research programme. Convene the people who understand the content, transaction, support operation, programme rules, and vendor relationship. Trace the route they believe a person takes, then check the destinations. This follows the service-design principle in the UK Government Service Standard’s requirement to understand users and their needs, while remaining feasible for teams working with limited staffing, legacy content-management systems, or fixed procurement cycles.
Check: Begin with a journey whose failure has a meaningful service consequence, such as a missed deadline, an unsubmitted request, an unavailable appointment, or a need to seek help through another channel. Keep the first route narrow enough that every handoff can be named.
The five cards that make up a service journey
Put each step on a card, spreadsheet row, or shared board. Record the actual destination, not the system your organization assumes is in use. A route often crosses a search result, service information, eligibility instructions, a hosted form, a PDF, an identity check, a payment tool, a confirmation message, and a support channel. The W3C Web Accessibility Initiative’s planning guidance treats accessibility as work that involves policy, people, processes, and technology, which is why this inventory should reach beyond the page editor’s remit.
| Journey card | What to record | Question for the test | Likely owner |
|---|---|---|---|
| Find the service | Search result, referral, or landing page | Can the service be identified and understood? | Content or communications |
| Establish eligibility | Questions, instructions, or a document | Can requirements be read and completed? | Programme team |
| Complete the transaction | Form, payment tool, or scheduler | Can every required control be operated? | Product team or vendor |
| Receive confirmation | Screen message, email, or text | Is status clear in an accessible format? | Service operations |
| Recover or get help | Contact route or resubmission path | Can the person continue without starting over? | Support and programme team |
Circle the handoffs before testing the cards
Mark every change of system, owner, or communication channel. Those boundaries are where responsibility can become diffuse: a scheduler may be vendor-hosted, an instruction may sit in a PDF, and a confirmation may be sent by an operations platform. An appointment route is incomplete when its confirmation provides a date yet no usable way to reschedule. A benefits route is incomplete when the instructions needed to finish it appear only in an inaccessible PDF. The barrier is in the route the institution has asked people to follow, not merely in a single interface.
Section 508, the U.S. federal accessibility law for information and communication technology (ICT), applies to federal agencies. State and local agencies, schools, and healthcare organizations can face different laws, policies, funding conditions, and contract terms. The map does not settle legal responsibility and is not legal advice. It identifies the components that accessibility staff, counsel, procurement staff, and service owners may need to review together.
Use two routes to turn the map into an accessibility test
The first route is the ordinary path: can a person complete the intended task from beginning to end? The second is the recovery path: what happens when information is missing, an error occurs, a session expires, or help is needed? Keeping both routes on the same map changes the audit from a collection of screens into an examination of service continuity. A page-by-page review can find important defects, although it may not reveal whether a person is stranded when the transaction becomes complicated.
Write scenarios that preserve the public purpose
Write each route as a short scenario with a task, starting point, and expected result. “Using only a keyboard, request a building inspection and reach a confirmation that explains what happens next” is more useful than “test keyboard accessibility,” because it retains the service purpose while making the test observable. WCAG 2.2 Success Criterion 2.1.1, Keyboard requires functionality to be operable through a keyboard interface, subject to its stated exceptions.
Apply checks that fit the card rather than treating an automated scan as a verdict. Test keyboard operation and focus order at interactive steps; test labels, instructions, and error messages where information is entered; test confirmation status after submission; and test the route to assistance when recovery is needed. WCAG 2.2 Success Criterion 3.3.1, Error Identification requires automatically detected input errors to be identified to the user. WebAIM’s keyboard-accessibility guidance explains the practical importance of visible focus and predictable keyboard operation.
Give each finding back to the owner who can act
Log the barrier beside its journey card, the effect on completion, the component owner, and the next decision. A content editor may own unclear instructions. A programme office may need to clarify an eligibility rule. A vendor may need to correct a scheduling interface. An operations team may need to revise confirmation or support. Assigning every issue only to “website accessibility” conceals the decisions needed to repair the service.
For a vendor-controlled card, retain the scenario and barrier in the contract record or issue log, then ask how the component supports the applicable standard and how a correction will be retested. A Voluntary Product Accessibility Template (VPAT) is a vendor-produced accessibility conformance report format; Information Technology Industry Council guidance on VPATs describes its use in accessibility procurement. A VPAT can inform due diligence, while a journey test asks whether the institution’s actual service can be completed.
Do: Bring one mapped outcome, its recovery route, and an owner for every handoff to the next release-planning or vendor-governance meeting. That modest artifact can establish a credible scope before the team commits to a broader page audit.
Key takeaways
- An accessibility test should begin with the public outcome a person needs to achieve, not with a website navigation structure.
- A journey map should include documents, third-party tools, confirmations, and help routes whenever they are necessary to complete the service.
- Testing an ordinary route and a recovery route exposes barriers that a page-by-page audit may not reveal.
- WCAG checks remain necessary, while journey scenarios show whether accessible components form a usable public service.
- Each finding should go to the owner of the relevant service step, including content, programme, operations, and vendor teams.
Questions readers ask
Is a page audit enough to test a public service?
A page audit can identify defects on individual pages. A journey test examines whether pages, tools, documents, messages, and help routes allow someone to complete an outcome.
Which journey should a small team map first?
Choose a task whose failure blocks a consequential service, such as an application, appointment, payment, enrolment action, or required notice. Keep the first map narrow enough to include its handoffs and recovery route.
Should vendor-hosted forms appear in the inventory?
Include a vendor-hosted form when a person must use it to obtain the service. Record the institutional owner, the relevant scenario, and the route for escalating a defect.
Does a VPAT replace journey testing?
No. A VPAT is a structured vendor conformance report, whereas a journey test asks whether the institution’s actual service can be completed from start to finish.