A public service website audit is most useful before the complaint arrives, while there is still time to fix the journey instead of defend the failure.
Inventory the journey people actually have to finish
A page inventory can tell you how many URLs exist. It cannot tell you whether a resident can renew a permit, pay a fee, request an accommodation, download the right form, recover from an error, or keep proof that the task is complete. Public-service accessibility fails in the spaces between pages: search results, department landing pages, PDF packets, third-party forms, payment widgets, confirmation screens, and phone-number fallbacks that lead people in circles.
A previous guide on this site, "How to audit a public service website before the complaint arrives," established that audits should start with services rather than pages and that every finding needs a named owner. This piece takes that premise one step further: it specifies what the service-level record itself should contain once the audit begins, so that "start with services" becomes a document a team can actually fill out rather than a principle they nod at and then revert to a page checklist anyway.
The service map comes before the checklist
For each journey, write down the starting point, the task, the required evidence, the surfaces involved, and the point where failure would cost someone time, money, eligibility, safety, housing, schooling, or a legal deadline. Only then should the checklist come out. Otherwise the audit becomes a technically impressive list of pages with no answer to the human question: could someone finish the service?
ADA.gov's Title II web rule overview helps frame the public-entity obligation. The World Wide Web Consortium's Web Accessibility Initiative (W3C WAI) publishes evaluation guidance that helps keep the work repeatable. The local method should combine both: service consequence plus testable evidence.
What a completed journey record actually looks like
The service map stays abstract until a team fills one out completely. Consider a task many local governments offer online: renewing a residential parking permit. A completed record for that single task might read like this.
| Field | Example entry |
|---|---|
| Task | Renew a residential parking permit |
| Starting point | City services homepage, "Parking" link |
| Required evidence | Proof of residency uploaded as a PDF, license plate number, payment |
| Surfaces involved | Landing page, third-party payment portal, confirmation email |
| Observed barrier | Payment portal iframe traps keyboard focus after a validation error |
| User impact | A resident using only a keyboard cannot correct the error or complete payment |
| Owner | Vendor (payment portal); the city's information technology (IT) department holds the contract |
| Workaround | Phone line listed on landing page, staffed weekdays 9 to 4 |
| Retest path | Re-run keyboard-only test through payment step after vendor patch ships |
Notice what the record does that a page-by-page scan cannot. It shows that the landing page itself may pass every automated check while the task still fails two steps later, inside a vendor's iframe that the city's own developers cannot edit directly. It gives legal a specific, time-stamped barrier rather than a general complaint risk. It gives the program owner a workaround to publish immediately, and it gives IT a contractual lever to raise with the vendor instead of an open-ended "accessibility issue" that nobody is positioned to close. None of this promises legal compliance; it only makes clear, prior to any dispute, what a reasonable team already knew and did about the barrier.
The same nine fields work for other recurring services: a fee waiver request, a public records request, an accommodation request for an assessment center, or a utility hardship program. What changes from service to service is the barrier and the owner, not the structure of the record. That consistency is what lets an audit scale past one team's favorite example: a legal reviewer, a new hire, or an auditor from outside the organization can read any completed record and understand the task, the failure, and the accountable party without translation.
Follow the evidence across handoffs
A good service inventory names every handoff. The page may be owned by a communications team using a shared content management system (CMS). The form may be owned by a program team. The payment step, as in the example above, may be owned by a vendor. The PDF may come from a source document nobody has touched in years. The confirmation email may be controlled by a system administrator. If the audit record does not name those owners, the fix can disappear even after everyone agrees it matters.
For each handoff, capture the URL or document location, the interaction state, the observed barrier, the user impact, the owner, the workaround if one exists, and the exact retest path. That is the difference between "we found accessibility issues" and "we know which public service failed, why it failed, and how we will prove the repair."
The handoff view also changes who needs to be in the room. A communications team can fix page headings but not a vendor payment flow. A program owner can rewrite instructions but may not control the CMS template. Legal can name risk but cannot retest a keyboard trap. The service map makes those dependencies visible before a complaint forces the organization to discover them under pressure.
Make the board tell the truth
The status system should mirror the journey, not hide it. A page can pass a scan while the service is still blocked one step later, exactly as it did in the parking-permit example. A PDF can be remediated while the form that links to it remains confusing. A payment widget can work with a mouse while keyboard focus disappears after a validation error. The board needs a place for those findings to live without pretending the whole service is fixed.
This is where monitoring can help after repair: repeated template failures, changed pages, and drift are easier to catch when the service inventory already names what matters. Monitoring is not the journey test. It is the smoke alarm attached to a journey the team understands.
That truthfulness matters for morale as much as compliance. Teams lose trust in dashboards when every item says "done" while residents are still stuck. A journey-level board can say something more useful: the landing page is fixed, the PDF is waiting for an owner, the vendor form needs escalation, and the retest is scheduled against the original task.
A better first audit
Choose one service with consequences and audit it end to end. Keep the scope small enough to finish. The deliverable is not a wall of URLs; it is a completed record, built on the model above, that names the task, the barriers, the owners, and the retest evidence.
When the board brings that draft back for review, the editor should be able to see the resident path, the public promise, the failure point, and the next proof needed without reconstructing the whole story from comments.