A public service or workplace task often crosses several products: a website, identity provider, form, payment or document system, notification and support channel. Each component contributes to the outcome. Map the journey from the user’s starting point to the final usable result, then make the boundaries between systems part of the test plan. This is integration work as much as page design.
Map a complete journey
Choose an essential task, such as applying for a permit or obtaining a training record. Write the steps in the order a visitor encounters them. Beside each step, record the system, supplier, account role, input, output and responsible team. Include instructions sent by email, downloaded files and any help route.
Add the paths people take when something goes wrong: an expired session, rejected upload, incorrect entry, unavailable appointment or failed identity check. Describe how someone returns to the task with their work intact. A diagram can reveal missing ownership, but a simple ordered list is enough to begin.
Test the transitions explicitly
- Entering a system: can the visitor understand the new page and reach its controls using their access tools?
- Carrying context: does the service preserve the information needed for the next step, including explanations and any corrections?
- Returning: after a separate service finishes, can the visitor locate confirmation and continue?
- Receiving output: is the receipt, document or message usable in the form delivered?
- Recovering: can the visitor understand a failure and reach an effective support route?
Use fictional data and authorized test accounts. Repeat the whole journey with the relevant keyboard, zoom and assistive-technology checks; a supplier demonstration of an isolated screen covers only that screen. W3C’s guidance on involving users explains how user participation complements evaluation expertise.
Agree who investigates and who repairs
Assign an owner for the complete user outcome as well as owners for individual systems. When a barrier is found, the service owner should coordinate investigation instead of asking the user to determine which supplier is responsible. Keep a shared issue identifier when evidence moves between organizations.
Define the evidence a vendor needs: product and integration version, configuration, role, reproduction steps and expected result. Establish a route for time-sensitive barriers and an agreed way to retest a delivered fix. Use the Section 508 procurement guidance where federal requirements apply, and have the appropriate team determine other contractual or legal obligations.
W3C’s planning guidance includes responsibilities, resources and monitoring. For an integrated service, turn that plan into explicit responsibility for each boundary and the final output.
Follow a boundary failure to its conclusion
Make the completion condition observable. For this example, it includes finding the certificate, identifying the course and learner details, and reading the relevant information in the supported environment. Keep personal data out of shared test evidence.
Retest when the connection changes
Record the versions and configuration used in the successful test. A changed identity flow, embedded widget, document template or notification service can alter access even when the main website is unchanged. Maintain a small set of representative journeys that crosses those boundaries.
After a supplier update, test the affected transition and its failure routes. Confirm who maintains any temporary access arrangement and how users find it. Report remaining gaps by task and impact, with owners and review dates, so the next release has a clear starting point.