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.
The evidence boundary
The audit you want is the one you can open after a complaint and say: here is the journey we tested, here is where it failed, here is who owned the fix, and here is the retest. That is more useful than a spreadsheet with two hundred URLs and no story.
A public service website audit should start with one resident trying to finish one consequential service. Renew this permit, pay this bill, request this accommodation, download this form, meet this deadline. The unit of work is not a page. It is a public promise.
That framing matters because public-sector accessibility is not just a design preference. Title II obligations and the 2024 web rule put public entities under a practical clock for web and mobile accessibility. The rule does not make every team instantly ready. It does make vague readiness plans harder to defend.
Start with services, not pages
The fastest way to make an audit useful is to pick a representative journey. A representative journey is a real path through a public service. It may start with search, move through a department page, ask the person to open a PDF, send them into a form, hand them to a vendor-hosted payment screen, and end with a confirmation number they need later.
That is usually where the trouble lives. The landing page is clean. The service breaks one click later. The PDF is scanned, the form error is vague, the payment widget loses focus, or the “call this office” fallback sends the person back to the same broken page. A page inventory will count all of that. A service-journey audit will show what actually happened.
ADA.gov's Title II web rule overview is the first reference to keep close because it explains the public-entity context in plain language. W3C WAI's evaluation guidance is the second because it keeps the audit grounded in repeatable testing rather than vibes, screenshots, or vendor confidence.
Build the complaint-ready evidence packet
Before pressure arrives, build the record you would want six weeks later when someone asks what the agency knew, what changed, and whether the fix worked. For each service journey, document:
- Service promise: what the public is supposed to be able to do.
- Starting assumption: where a member of the public would reasonably begin.
- Task: what the person is trying to complete and what proof they need afterward.
- Surfaces involved: pages, forms, documents, and third-party systems.
- Checks run: the accessibility checks used at each step.
- Failure state: URL, selector, screenshot, document page, or interaction state when useful.
- Public workaround: whether a realistic backup path exists.
- User impact: the problem in plain language, without WCAG shorthand.
- Evidence owner: the team or person responsible for the next fix.
- Retest proof: the retest date, result, and same path used for confirmation.
This keeps the audit from turning into a blame document. It becomes a complaint-ready evidence packet: a task, a finding, a risk, an owner, and a retest trail that different teams can understand without reconstructing the whole incident from memory.
For the first pass, resist the urge to audit everything equally. If failure costs someone money, time, eligibility, safety, housing, schooling, or a legal deadline, it outranks a prettier informational page. This keeps scarce remediation time attached to public need, not internal noise.
What to test first
Start with the journeys where a broken task changes somebody's day: benefits, deadlines, payments, forms, emergency information, complaints, accommodations, enrollment, permits, and required documents. Then test the common access points around those journeys: navigation, search, page headings, labels, errors, keyboard operation, focus order, link purpose, contrast, language, captions, and document structure.
Automated tools help, but they cannot tell the whole story. They are good at catching some repeatable failures quickly. They are weaker at judging whether instructions make sense, whether a PDF is usable for the actual task, whether a form error helps someone recover, or whether the journey works when a person is stressed and short on time.
Make the audit legible to leaders
Public-sector teams often fail because the evidence is trapped between departments. A finding should survive four readings: legal can see the risk, IT can find the defect, the program owner can see the broken service, and communications can explain the public impact without translating jargon.
That usually means writing the same issue in more than one register. For legal, the issue is exposure around a required public service. For IT, it is a selector, template, vendor component, or document defect. For the program owner, it is a blocked permit, payment, accommodation, enrollment, or deadline. For communications, it is the plain-language answer to “what should we tell the public while this is being fixed?”
A useful audit report separates severity from embarrassment. Do not start with “the website is bad.” Start with “this journey blocks a resident from completing this service without help.” Then name the evidence. Name the owner. Name the next test. If a third-party form, payment processor, map, scheduling tool, or document vendor is involved, say so directly.
Assign owners before fixes disappear
The most common pre-complaint failure is not that nobody found the issue. It is that the issue was found, shared, and then dissolved into a meeting note. A useful audit gives every finding a destination. Template problems go to the design system or CMS owner. Form problems go to the service team and the vendor if the form is third-party. Document problems go to the document owner and the team that controls the source file, not only the person who uploads PDFs.
Retest the same path, not the nearest convenient page. A fix is not complete because a ticket moved columns. It is complete when the original journey is run again and the evidence changes. If the original failure was a keyboard trap in step three of a form, step three is where the fix has to prove itself. If it found a document that could not be navigated by headings, retest the corrected document, not only the landing page that links to it.
This is where a possible Silktide angle could be useful, but only if it helps explain monitoring after repair. Ongoing checks can help teams notice drift, repeated template failures, and pages that change after launch. They do not prove that the original service journey works unless the journey is retested.
The practical change to make next
Pick one service with a deadline and run it from the public starting point. Save the page, the form state, the document, the error, the scan result, the assistive-technology note where possible, the owner, and the retest plan. Keep the scope small enough that the team can finish it instead of admiring the size of the backlog.
The goal is not to prove that the whole website is perfect. The goal is to have the evidence, ownership, and retest trail already in place before the first angry email becomes the project brief. When the complaint comes first, the team reconstructs evidence under stress. When the audit comes first, the team already knows the journey, the failure, the owner, and the next fix.
A pre-complaint audit is not a shield against accountability. It is the habit of making accountability visible before someone has to demand it.