City and County Website Compliance Checklist

TL;DR: City and county websites are public entities under ADA Title II and must meet WCAG 2.1 AA (target 2.2 AA) by April 24, 2026 if your population is 50,000+, or April 26, 2027 if smaller. But accessibility is only one column of the ledger — your site also needs a current privacy policy and cookie consent, HTTPS with security headers, accessible permit and payment forms, tagged agenda/minutes PDFs, and accountability for the third-party portals (payments, GIS, agendas) you embed. This checklist is the municipal master list, organized so you can assign and track each item.

A city or county website is one of the most legally exposed digital properties a government operates. It’s the front door for permits, payments, public records, council agendas, and emergency information — and it’s continuously scanned by serial ADA complainants and plaintiffs’ firms who file complaints with the DOJ and Office for Civil Rights. With the 2024 DOJ ADA Title II final rule setting hard, dated accessibility requirements, “we’ll get to it” is no longer a defensible posture.

This city and county website compliance checklist is the municipal master list. It pulls together accessibility, privacy, security, forms, PDFs, and vendor management into one set of checkable items tailored to local government. It’s a focused companion to the general government website compliance checklist, and part of a cluster that includes the public library and state agency checklists.

Step 0: Find Your Deadline by Population Tier

The DOJ rule staggers compliance by the population of your jurisdiction:

• Population 50,000 or more: comply by April 24, 2026.
• Population under 50,000 (and all special district governments): comply by April 26, 2027.
• Use your jurisdiction’s official population (Census). A county uses its total county population; a city uses city population.
• The legal standard is WCAG 2.1 Level AA, but adopt WCAG 2.2 AA — it adds nine criteria and is the safer, future-proof target.

If you’re a smaller jurisdiction, the small local government accessibility guide and the local-government deadline breakdown go deeper on a right-sized approach.

Section 1: Accessibility (WCAG 2.2 AA)

Images and Media

• All meaningful images have descriptive alt text; decorative images use alt="" (SC 1.1.1).
• Council/commission meeting videos and public-service videos have accurate synchronized captions (SC 1.2.2), not raw auto-captions.
• Audio-only content (recorded hearings, announcements) has a transcript.
• Maps (zoning, districts, service areas) and infographics have text descriptions or accessible data alternatives.

Color and Contrast

• Body text meets 4.5:1 contrast (SC 1.4.3); large text and UI components meet 3:1 (SC 1.4.11).
• Information is never conveyed by color alone (e.g., required fields, alert statuses).
• Content reflows at 320px width and 400% zoom without horizontal scrolling (SC 1.4.10).

Keyboard and Navigation

• All functionality works with the keyboard alone, with no keyboard traps (SC 2.1.1–2.1.2).
• A visible focus indicator is present and not obscured by sticky headers (SC 2.4.7, SC 2.4.11 in WCAG 2.2).
• A “Skip to main content” link is present (SC 2.4.1).
• Drag-only interactions have a single-pointer alternative (SC 2.5.7); target sizes meet 24×24 CSS px (SC 2.5.8).

Structure and Content

• Pages use one <h1> and logically nested headings.
• Page <title> and lang attribute are set.
• Link text is descriptive (“Apply for a building permit,” not “click here”).
• Tables (fee schedules, election results) use proper header markup.

Section 2: Forms — Permits, Payments, and Service Requests

Forms are where local government sites do real transactional work, and they’re a top source of accessibility complaints because a broken form blocks a public service entirely.

• Every input has a programmatically associated <label> (not placeholder-only).
• Required fields are marked with text/aria-required, not color alone.
• Error messages identify the field and explain the fix in text (SC 3.3.1, 3.3.3); errors are announced to screen readers.
• Multi-step flows (permit applications, business licenses) expose progress and are fully keyboard-operable.
• Inputs that collect personal data use correct autocomplete attributes (SC 1.3.5).
• No essential form relies on CAPTCHA that fails SC 3.3.8 (accessible authentication / cognitive-function tests).
• See the full pattern in accessible government forms.

Section 3: PDFs — Agendas, Minutes, and Records

City and county sites are PDF factories: agendas, minutes, staff reports, ordinances, budgets, RFPs. Most are linked from the public site and therefore in scope.

• Inventory linked PDFs and prioritize active, high-traffic documents (current agendas, packets, forms, fee schedules) for PDF accessibility work.
• Born-digital PDFs are tagged, have a logical reading order, document title and language, and alt text on images.
• Scanned documents (signed ordinances, old minutes) are OCR’d and tagged — a scanned image PDF is unreadable to screen readers.
• Move recurring content (agendas, minutes, meeting calendars) to HTML where practical; HTML is easier to keep accessible than PDF.
• Where a large legacy archive can’t be fully remediated by the deadline, document a prioritization plan and conforming-alternate-version approach.

Section 4: Online Payments and Third-Party Vendors

Much of a municipal site is embedded vendor software — payment portals (utility bills, taxes, citations), permit/licensing systems, GIS viewers, agenda-management platforms (Granicus, CivicPlus, NovusAGENDA), and the CMS itself. You are responsible for the accessibility of services you offer the public, even when a vendor delivers them.

• Inventory every embedded/linked third-party system and its vendor.
• Request a current VPAT for each; read it critically per the VPAT procurement guide.
• Test the live integration: complete a payment, file a request, and view an agenda using keyboard-only and a screen reader — VPATs describe the product, not your specific configuration.
• Add accessibility and security clauses to renewals and RFPs: require WCAG 2.1/2.2 AA conformance, a current VPAT, and defect remediation timelines. The compliance tool procurement guide has reusable clause language.
• Confirm payment processors are PCI DSS compliant; never store card data in your CMS.
• Where a vendor system is inaccessible, document an equally effective alternative (phone, in-person, mail) and publish it.

Section 5: Privacy and Cookies

• Publish a current, specific privacy policy that names what you collect (forms, payments, analytics), why, retention, and how to request records.
• Implement a compliant cookie banner where required; ensure non-essential trackers don’t fire before consent.
• Audit third-party trackers — embedded maps, social widgets, chat, and analytics frequently send constituent data to external networks.
• Check obligations under applicable state privacy laws (e.g., CCPA/CPRA-style or emerging state laws).
• Confirm vendor contracts (payments, CRM, analytics) restrict how constituent data is used and shared.

Section 6: Security — HTTPS, Headers, and Hardening

• Enforce HTTPS site-wide with HSTS; redirect all HTTP traffic.
• Monitor TLS certificate expiry with alerting — an expired cert takes down the whole site, including emergency information.
• Configure baseline security headers: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy, Permissions-Policy.
• Keep CMS, plugins/modules, and themes patched; remove unused/abandoned ones.
• Follow CISA’s recommendations for government websites; consider migrating to a .gov domain (free for U.S. governments) for trust and DNS protections.
• Require MFA on all admin/CMS accounts; deprovision departed staff promptly.

Section 7: Governance and Continuous Monitoring

The deadline is a starting line, not a finish line. Your site changes constantly — new agendas weekly, new staff publishing pages, vendor updates you don’t control — and each change can introduce a regression.

• Publish an accessibility statement with a feedback mechanism and named contact (the DOJ rule expects a way to report barriers).
• Designate an accessibility/ADA coordinator and train content contributors.
• Run a baseline accessibility audit and track remediation to closure.
• Maintain a vendor accountability log (VPATs, tickets, contract terms).
• Adopt continuous automated monitoring so newly published pages, PDFs, and vendor changes are flagged immediately. See continuous compliance monitoring for government.

A city or county website is never “done,” and neither is its compliance. The jurisdictions that get caught flat-footed by a DOJ complaint aren’t usually the ones that ignored accessibility entirely — they’re the ones that remediated once, passed an audit, and then let the site drift for a year while clerks posted untagged agendas and a vendor pushed an inaccessible portal update. Govzu monitors your full municipal web presence continuously, catching accessibility, privacy, and security regressions as they appear and giving your team a defensible, time-stamped record of good-faith compliance ahead of the 2026 deadline and beyond.