Skip to content
Back to BlogGovernment

WCAG Accessibility for Government Websites: A Plain-Language Checklist

What the DOJ's Title II rule requires of state and local government websites, the WCAG 2.1 AA checkpoints that matter most, and how to sequence fixes.

Vitalli OgarVitalli Ogar
··5 min read
Hands navigating a laptop using the keyboard
Key takeaways
  • Web accessibility is now a legal requirement for state and local governments: the DOJ's Title II rule sets WCAG 2.1 AA as the standard, and the first compliance deadline passed in April 2026.
  • Most accessibility failures cluster in a handful of patterns: low contrast, missing alt text, unlabeled form fields, empty links and buttons. Fixing those four patterns resolves the bulk of typical errors.
  • Keyboard access is the fastest honest test. If you cannot reach and use every control on a page with Tab, Enter, and arrow keys, neither can many residents.
  • Remediate by traffic, not by sitemap. The twenty pages and three forms residents actually use matter more than a perfect score on pages nobody visits.

For years, accessibility on government websites lived in the gap between “we should” and “next budget cycle.” The Department of Justice closed that gap. Its rule under Title II of the ADA makes WCAG 2.1 Level AA the required standard for state and local government web content, with the first compliance deadline, for entities serving 50,000 or more people, already passed in April 2026. Smaller entities and special districts have until April 2027, which is close enough that remediation should be on a calendar today.

This checklist is for the person who owns that calendar: the communications or IT lead who needs to know what the standard actually demands, what to fix first, and what to ignore. It is a companion to our government digital marketing guide, where accessibility sits alongside plain language and findability as one of the three legs of public-sector communication.

What WCAG 2.1 AA actually asks for

WCAG is a long document, but its demands cluster around four plain ideas, and the standard itself names them: content must be perceivable, operable, understandable, and robust.

  • Perceivable. Text alternatives for images. Captions for video. Color contrast strong enough to read outdoors on a phone. Nothing conveyed by color alone.
  • Operable. Everything works by keyboard. Nothing traps focus. Users get enough time, and nothing flashes in seizure-inducing patterns.
  • Understandable. Pages declare their language. Navigation is consistent. Forms label their fields and explain their errors in words, not just red outlines.
  • Robust. Markup is clean enough that assistive technologies, screen readers, magnifiers, voice control, can parse it reliably.

None of this is exotic engineering. It is the difference between a form field with a visible label and one with placeholder text that vanishes on focus.

Where government sites actually fail

Audit data is unambiguous about where the problems live. WebAIM’s annual analysis of the top million home pages finds detectable WCAG failures on well over nine in ten sites, and the same handful of error types accounts for the overwhelming majority: low-contrast text, missing image alt text, missing form labels, and empty links or buttons.

That distribution is good news for anyone with a remediation budget, because it means most errors are cheap, repeated patterns rather than deep architectural flaws. Fix the pattern in the template and the fix propagates everywhere the template renders.

Government sites add two failure modes of their own:

  • The PDF archive. Decades of scanned agendas, fee schedules, and forms that screen readers cannot parse and phones cannot comfortably display. The rule covers documents residents need to use, so essential content belongs on web pages, with PDFs as the formal record behind them.
  • The third-party tool. Payment processors, permit portals, agenda systems, and form builders procured years ago. The public entity remains responsible for what residents experience, which makes accessibility language in procurement contracts a compliance tool, not boilerplate.

And one anti-pattern deserves its own sentence: overlay widgets that promise one-line compliance do not deliver it, do not fix the underlying code, and have not prevented complaints. Money spent there is money not spent on real fixes.

The honest quick test

Before commissioning anything, run the test that costs nothing. Put the mouse away and complete your most common resident task by keyboard alone: Tab through the navigation, reach the form, fill every field, submit it, and read the confirmation.

If you get stuck, so do residents using screen readers, voice control, switch devices, or simply a broken trackpad. In our own website work this single pass surfaces more real-world barriers than any scanner report, because it tests the task, not the markup.

Sequencing remediation

The standard covers everything; your budget does not. Sequence by resident impact:

  1. Inventory by traffic. Pull the twenty most-visited pages and the three most-used forms from analytics. That list, not the sitemap, is the remediation plan.
  2. Scan, then fix the four big patterns. Contrast, alt text, form labels, empty links. Template-level fixes first, so they cascade.
  3. Keyboard-test the money tasks. Payments, applications, records requests. Fix focus order, focus visibility, and anything unreachable.
  4. Screen-reader-test the same tasks. Automated tools catch roughly a third of real barriers; this pass catches the rest of what matters.
  5. Rescue essential PDFs. Convert the content residents need into pages; keep documents as the archival copy.
  6. Put accessibility in procurement and publish a statement. Every new tool inherits the requirement, and a public accessibility statement with a working contact channel turns complaints into reports instead of filings.

Federal teams will recognize this shape from Section 508 practice; the Title II rule effectively extends the same discipline to every city, county, school district, and special district in the country.

Accessibility is communication policy

The framing that unlocks budget is recognizing that accessibility is not an IT line item. A resident who cannot read the fee schedule, complete the form, or operate the menu has been told, in effect, that the institution was not built for them. The DOJ rule makes that a legal problem; it was always a trust problem.

The institutions handling this well treat accessibility the way they treat plain language: a standing standard applied to everything new, plus a scheduled, prioritized cleanup of what exists. That is steady work rather than a heroic project, and it is exactly the kind of work that separates the public institutions residents trust from the ones they complain about.

If your entity is staring down the 2027 deadline with a long sitemap and a short budget, Pacific54 has done this triage with South Florida public institutions. Reach out and we will help you find the twenty pages that matter.

Frequently asked questions

What accessibility standard applies to government websites?

For state and local governments, the Department of Justice's 2024 rule under Title II of the ADA sets WCAG 2.1 Level AA as the required standard for web content and mobile apps. Entities serving 50,000 or more people had until April 2026 to comply, and smaller entities and special districts have until April 2027. Federal agencies follow Section 508, which references the same WCAG standard.

Does an accessibility overlay widget make a government site compliant?

No. Overlay widgets that promise one-line compliance do not fix the underlying code, and pages using them show roughly as many detectable errors as pages without them. Screen reader users frequently report overlays making sites harder to use, and overlays have not prevented complaints or litigation. Compliance comes from accessible markup, labeled forms, sufficient contrast, and keyboard support in the site itself.

How do we check if our government website is accessible?

Start with three passes. Run an automated scanner on your highest-traffic pages to catch contrast, alt text, and labeling errors. Then test those same pages by keyboard alone: every link, menu, and form field should be reachable and usable with Tab and Enter. Finally, complete your most common resident tasks with a screen reader. Automated tools catch perhaps a third of real barriers, so the manual passes are not optional.

What should a small government fix first with a limited budget?

Sequence by resident impact. Fix the pages and forms that carry the most traffic first: the payment flow, the top permits and applications, the contact and hours pages. Address the error patterns that dominate real-world audits, contrast, alt text, form labels, and empty links, since they are common, high-impact, and inexpensive to fix. Pull essential information out of scanned PDFs into web pages. A perfectly accessible sitemap can wait; the tasks residents complete every day cannot.

Vitalli Ogar
About the author
Vitalli Ogar · Web Development

Develops the sites and landing pages: fast, maintainable builds that hold up long after launch.