Municipal and county website accessibility checklist

Map the essential resident services

Inventory paying a bill, requesting a permit, applying for benefits, attending a meeting, finding emergency information, and reporting a problem. Note domain changes, authentication, third-party forms, downloadable documents, and mobile-app dependencies along each path.

Assign a service owner and technical owner. A department can publish the instructions while a vendor controls submission; both sides need a repair and escalation path. A crawl boundary should be explicit so vendor-hosted steps are not mistaken for completed testing.

Test the shared site framework

Verify menu operation, search, focus order, skip navigation where applicable, meaningful headings, readable contrast, and reflow. Check that links and controls have understandable accessible names. Test dynamic results and error states rather than only the initial page.

A shared template repair may address many occurrences. Preserve the affected URL list, but give the vendor one coherent component-level action with acceptance criteria. Recheck representative pages from each department after the change.

Prioritize current documents and public meetings

Identify the documents residents need for current services: application forms, notices, meeting packets, and instructions. Keep editable sources and publisher ownership. Validate exported PDFs and manually inspect reading order, links, table structure, and meaningful alternatives.

Caption public-facing media appropriately and assess whether visual information needs description. Embedded players and meeting platforms need keyboard and assistive-technology checks. Check embedded content according to what it contains: a PDF needs document-accessibility review, while a video needs checks for captions, audio description where appropriate, and accessible playback controls.

• Label document links with a meaningful purpose and format.
• Record broken or unavailable links separately from accessibility failures.
• Document any exception decision and alternative access process.
• Keep the latest accessible source and version history for frequently updated forms.

Make procurement and acceptance testable

Request accessibility evidence for the actual version and configuration being purchased. Ask what was tested automatically, what was tested manually, known limitations, and how fixes are delivered. Contract responsibility should be specific enough to resolve a failing real-world transaction.

Acceptance should include completing an important task using keyboard and assistive technology, handling errors, receiving confirmation, and obtaining necessary records. Do not approve an entire service based solely on a vendor’s statement or a passing homepage scan.

Maintain a living repair register

Track the URL or service, barrier, source evidence, owner, priority, planned repair, and retest outcome. Prioritize service impact and broad shared-component reach, not just raw finding counts.

Provide an accessible contact route for residents who encounter a barrier. Review new content before publication and revisit the register after redesigns, vendor updates, and new document workflows. A statement should describe the actual process and limitations, not promise that every page is compliant.