Government and Public-Sector Web Accessibility Beyond Section 508

For a long time, "government web accessibility" in the United States meant one thing: Section 508, the standard that applies to federal agencies. If you worked for a city, county, school district, or state agency, the rules felt fuzzier — the ADA clearly applied, but there was no explicit technical standard telling you what your website had to do.

That era is over. The Department of Justice's rule under Title II of the ADA gives state and local governments a concrete standard and concrete deadlines. The first of those deadlines has already passed, and the second is close. Here's what public-sector teams need to know — and why this is fundamentally about serving residents, not dodging trouble.

The new baseline: WCAG 2.1 AA for state and local government

The DOJ rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA. The deadlines are staggered by size:

• April 2026 for public entities serving populations of 50,000 or more.
• April 2027 for smaller entities and special district governments.

"Public entity" is broad. It covers state agencies, cities, counties, towns, public schools and universities, public libraries, courts, transit authorities, and the many special districts that run water systems, parks, and fire services. If your organization is part of state or local government, this rule almost certainly applies to you.

The scope is broad too. It's not just your main website — it includes the services residents actually use: online bill payment, permit applications, class registration, meeting agendas, court filings, and the documents linked from all of them. There are narrow exceptions for genuinely archived content and certain preexisting documents, but they're written tightly. The safe assumption is that anything a resident needs today is in scope.

Procurement is now an accessibility function

Here's the shift many public-sector teams underestimate: your obligations extend to the third-party tools you use to deliver services. If residents pay their water bill through a vendor's portal, that portal is part of how your government serves the public — and its accessibility is your concern.

That makes procurement one of the most important accessibility levers you have:

• Write accessibility into RFPs and contracts. Require WCAG 2.1 AA as a condition, not a preference.
• Ask vendors for conformance documentation — an Accessibility Conformance Report (often called a VPAT) — and read it critically. "Partially supports" on every line is a signal, not a formality.
• Verify before you sign. A short hands-on test — keyboard-only navigation, a screen reader pass on the main workflow — catches gaps that paperwork won't.

Teams that treat accessibility as a procurement requirement fix problems before they're deployed, which is orders of magnitude cheaper than remediating a live system a vendor controls.

Monitoring is ongoing, because your content is

A government website is never finished. Departments publish constantly — agendas, notices, schedules, emergency updates — and every publish is a chance for new accessibility issues to appear.

A typical example: a parks and recreation department publishes its seasonal program schedule as a flyer exported straight from a design tool — visually great, but an image of text that a screen reader can't read and a resident can't search. Nobody did anything wrong on purpose; the workflow just never asked the question. A one-time remediation project would have missed it entirely, because it was published after the project ended.

That's why the rule's practical demand is ongoing monitoring:

• Recurring automated audits across your sites, so new issues surface within days instead of years.
• A clear owner for accessibility findings in each department.
• Editor training on the recurring basics: alt text, heading structure, real text instead of images of text, accessible documents.
• A public accessibility statement with a working feedback channel — and a process that actually responds.

The point is residents, not deadlines

It's easy to frame all of this as regulatory pressure. The better frame is the one the rule itself is built on: government services are for everyone, and a website that a blind resident can't use is a government office with a locked front door.

Roughly one in four adults in the US lives with a disability. These are your taxpayers, voters, students, and transit riders. When your permit portal works with a screen reader and your meeting agendas are readable, you're not checking a box — you're doing the job government websites exist to do. Teams that internalize this tend to find the technical work more motivating, and their residents notice.

Where AllAccessible fits

AllAccessible is built for exactly this kind of sustained, accountable work:

• Continuous auditing across your sites and subdomains, mapped to WCAG, so you always know where you stand — before an audit or a complaint tells you.
• Human-in-the-loop agentic remediation: AllAccessible AI drafts fixes for the issues audits surface — image descriptions, link labels, form field names — and your staff reviews and approves every change before it goes live. Nothing ships without your sign-off, and every change is recorded and reversible. That review trail is precisely the kind of documented, ongoing effort public entities need to be able to show.
• An assistive widget that gives residents immediate options — text sizing, contrast, reading support — while your team works through the underlying fixes.

No vendor can promise that a website meets every requirement, and you should be wary of any that does. What we can promise is visibility into where you stand and a workflow that turns findings into approved, documented fixes at a steady pace.

Start before the deadline does

Whether your entity's date has passed or is still ahead, the path is the same: audit, prioritize the services residents use most, fix with human review, and keep monitoring.

Get started with AllAccessible and give your residents — all of them — a front door that opens.