Do you have a WCAG 2.2 AA city website? Two things are true about website accessibility for local governments right now. First, the legal standard under the Department of Justice’s ADA Title II rule is WCAG 2.1 Level AA, not 2.2. Second, a city that meets that standard only on launch day will likely fall out of conformance within months. This article sorts out the dates and standards, explains why WCAG 2.2 AA is the smarter build target, and shows why accessibility that gets patched after publishing leaves cities exposed.
The facts: deadlines and the required standard for a WCAG 2.2 AA city website
On April 20, 2026, the DOJ published an Interim Final Rule extending the Title II compliance dates by one year. The technical standard did not change.
| Public entity | Original compliance date | Current compliance date |
|---|---|---|
| State and local governments with a total population of 50,000 or more | April 24, 2026 | April 26, 2027 |
| Governments under 50,000 and all special district governments | April 26, 2027 | April 26, 2028 |
The required standard remains WCAG 2.1 Level AA. The DOJ has signaled it may review the rule further, but the extension moved only the dates. Your city’s existing ADA duty to communicate effectively with people with disabilities applies today, not only after the deadline.
If a vendor tells you the law requires WCAG 2.2, that is incorrect. If a vendor tells you WCAG 2.1 is all you will ever need to think about, that deserves a closer look too.
Why build to WCAG 2.2 AA if the law says 2.1?
The W3C published WCAG 2.2 as its current recommendation on October 5, 2023, and encourages organizations to use the most recent version. WCAG 2.2 is backward compatible with 2.1. It keeps every 2.1 success criterion except 4.1.1 Parsing, which was retired and which the W3C now treats as automatically satisfied for HTML. In practice, a site that conforms to 2.2 AA also meets 2.1 AA. Building to 2.2 AA therefore meets the Title II requirement with room to spare and prepares your site for any future update to the rule.
More importantly, the new success criteria cover exactly the tasks residents come to a city website to complete:
| WCAG 2.2 criterion | Level | Where it shows up on city websites |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers, cookie banners, and emergency alert bars that hide the element a keyboard user has selected. |
| 2.5.7 Dragging Movements | AA | 311 maps that require dragging a pin to report a location, and slider controls in forms. |
| 2.5.8 Target Size (Minimum) | AA | Tiny calendar dates, pagination links, and icon buttons on mobile. Targets generally need to be at least 24 by 24 CSS pixels. |
| 3.2.6 Consistent Help | A | Contact and help links that move around from page to page. |
| 3.3.7 Redundant Entry | A | Multi-step permit or registration forms that ask for the same address twice. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Puzzle CAPTCHAs or memory tests on payment portals and resident account logins. |
Many of these tasks live in third-party modules such as payment portals, 311 tools, and registration systems. That is why the WCAG version each vendor builds to matters.
Where the market stands
As of September 2026, CivicPlus’s published accessibility statement says the company has implemented the relevant portions of WCAG 2.1 AA as its standard and that its roadmap will prioritize any gaps against WCAG 2.2 AA. Its municipal website page describes sites as meeting WCAG 2.1 “at time of launch.” That page also mentions an accessibility checker in the editor and additional remediation, monitoring, and PDF conversion offerings. That approach targets today’s legal floor, and we are not suggesting otherwise.
The question every city should ask its vendor, including us, is simple: what keeps the site conformant after launch day?
The hidden risk: conformance decays after launch
A website is never finished. Every week, staff upload photos, paste in announcements, attach PDFs, and add buttons. Each edit is a chance to introduce a barrier.
WebAIM’s 2026 analysis of the top one million home pages shows how common that is:
- Automated testing found WCAG 2 failures on 95.9% of home pages, up from 94.8% in 2025.
- The average page had 56.1 errors, or roughly one barrier in every 26 page elements.
- Six error types account for 96% of everything detected: low-contrast text, missing alternative text, missing form labels, empty links, empty buttons, and missing document language.
Automated tools catch only part of the picture, so real conformance is likely worse.
Most of those errors are not exotic. They happen when a well-meaning editor uploads an image without alt text or picks a brand color that fails contrast. A template that was conformant at launch cannot stop them.
What “retroactively patched” looks like
When accessibility is not built into publishing, cities fall back on fixing problems after residents have already run into them. That usually takes one of three forms.
Scan-and-fix cycles. A monthly or quarterly scan finds errors that have been live for weeks. Scans are essential, but on their own they measure the problem. They do not prevent it.
Overlays. Overlay widgets add a script on top of the page instead of fixing the underlying code. In April 2025, the Federal Trade Commission finalized an order requiring overlay vendor accessiBe to pay $1 million. The order also bars accessiBe from claiming its automated tool can make any website WCAG compliant unless it has evidence to support the claim.
Remediation contracts. Paying a third party to fix what your platform let staff publish works, but it turns accessibility into a recurring expense instead of a default.
What preventive, built-in compliance looks like
The alternative is to make the accessible path the default path, so most errors never reach the public. In practice, that means:
- Accessible components. Editors build pages from pre-built components that already include correct headings, labels, contrast, focus states, and target sizes.
- Checks at the point of publishing. Issues are flagged while the editor is still working, not weeks later.
- Continuous monitoring. Automated scans catch what slips through, including problems in older content.
- A documented audit trail. Reports your ADA coordinator can hand to legal to show ongoing, good-faith effort.
This is how City of Anywhere is built. Our platform targets WCAG 2.2 AA, and staff build pages from components designed with accessibility guardrails. Automated scans run every month, and a detailed report is emailed to your team. When a scan finds an issue, it is classified, remediation steps go to your administrators, and our team is notified.
We will also be direct about the limits. No platform can guarantee immunity from legal claims, and anyone who promises that is overpromising. What a platform can do is prevent the most common errors, catch the rest quickly, and give you the documentation to prove it.
A 30-day checklist for clerks and ADA coordinators
- Confirm your compliance date. Check your population under the rule and whether you are a special district.
- Inventory every vendor that publishes to residents. Include payments, 311, agendas, registrations, and alerts. Request a current ACR from each and note which WCAG version it covers.
- Review your PDFs. The rule’s exception for pre-existing documents does not apply to documents residents currently use to apply for or access services, such as permit applications.
- Test your top five resident tasks against the WCAG 2.2 criteria above. Pay a bill, report an issue, find an agenda, apply for a permit, and sign up for alerts. Do each one using only a keyboard, then again on a phone.
- Publish an accessibility statement. Include a way for residents to report barriers and request alternatives.
- Document everything. Keep scan reports, remediation records, and vendor ACRs in one place.
Want a baseline? Run a free audit of your current site, and we will send back a WCAG 2.2 AA report whether or not you become a customer. For more detail, see ADA Title II Website Deadlines and How to Audit a City Website for ADA Compliance.
Frequently Asked Questions
Does ADA Title II require WCAG 2.2 AA?
No. The DOJ rule requires WCAG 2.1 Level AA. Building to WCAG 2.2 AA meets that requirement and also covers the newer success criteria.
Is a website built to WCAG 2.1 AA out of compliance?
Not if it actually conforms. The risk is that conformance at launch erodes as content changes. Ongoing monitoring and accessible publishing tools matter as much as the standard itself.
Do accessibility overlays make a city website compliant?
Overlays do not fix the underlying code. The FTC has penalized one overlay vendor for claiming its tool could make any website WCAG compliant. Fix the source instead.
Is my city responsible for a vendor’s inaccessible module?
Generally, yes. The rule covers content and apps provided through contractual, licensing, or other arrangements, so vendor-provided services are included. Talk to your city attorney about your specific contracts.
