ADA Title II Website Compliance: The Complete Guide for Local Governments (2026)

Your government website needs to be accessible to people with disabilities. That's been the law since 1990. But in April 2024, the DOJ finally spelled out exactly what "accessible" means: your website must meet WCAG 2.1 Level AA standards.

If your municipality has a population of 50,000 or more, you must comply by April 24, 2026. Everyone else has until April 26, 2027.

This guide explains what that means in practice — what's required, what's exempt, how much it costs, and how to get started today. Written specifically for city clerks, IT managers, and ADA coordinators at US local governments.

What the law actually requires

In April 2024, the DOJ published a final rule updating Title II of the Americans with Disabilities Act. For the first time in the ADA's 35-year history, the rule adopts a specific technical standard for digital accessibility.

The key points:

The standard is WCAG 2.1 Level AA. WCAG stands for Web Content Accessibility Guidelines, developed by the World Wide Web Consortium (W3C). Level AA is the middle of three conformance levels — it's considered the practical standard for most organizations. It includes 50 specific "success criteria" — testable requirements your website must meet.

It applies to everything digital. Websites, mobile apps, online forms, PDF documents, embedded videos, and even third-party tools hosted on your platform. If it's digital and provides a government service, it needs to be accessible.

Third-party content is your responsibility. If your website uses a third-party payment processor, form builder, or content management system, you're still responsible for making sure those tools are accessible. Update your procurement contracts to require WCAG 2.1 AA conformance from all vendors.

The rule is currently under review. In February 2026, the DOJ submitted a revised rule to OIRA as an Interim Final Rule. The specific changes haven't been made public, and the current deadline remains legally in effect. For a full analysis of the situation, read our article: Is the ADA Title II Deadline Being Delayed?

Who has to comply (and when)

April 24, 2026: State and local governments serving populations of 50,000 or more. This includes cities, counties, school districts, and any entity whose population (per the 2020 Census) hits 50K.

April 26, 2027: State and local governments serving populations under 50,000, plus all special district governments (utility districts, transit authorities, water boards, etc.) regardless of size.

How to calculate your population

• Cities and counties: Use your 2020 decennial Census population.
• School districts: Use the 2022 Small Area Income and Poverty Estimates.
• Entities without their own Census population (like a university or library): Use the population of the state or local government you're part of. A branch library in a county of 70,000 uses the county's population — and has to comply by April 2026.
• Special district governments: Always April 2027, regardless of size.

Important: There are no size exemptions. A village of 200 people has the same WCAG 2.1 AA requirement as New York City. The only difference is the deadline.

What WCAG 2.1 AA means in plain English

WCAG is organized around four principles, known by the acronym POUR. Your website must be:

Perceivable

People must be able to perceive the information on your site, even if they can't see, hear, or process information the way most people do.

What this means for your website:

• Every image needs a text description (alt text) that a screen reader can read aloud
• Videos need captions and/or transcripts
• Color can't be the only way you convey information (e.g., don't use "click the red button" if the button isn't labeled)
• Text must have enough contrast against its background (at least 4.5:1 ratio for normal text, 3:1 for large text)
• Users must be able to resize text up to 200% without content becoming unreadable

Operable

People must be able to navigate and interact with your website using whatever input method they use — keyboard, voice commands, switch devices, etc.

What this means for your website:

• Every function must work with just a keyboard (no mouse required)
• There must be a visible focus indicator showing where the keyboard cursor is
• Users need enough time to read and complete tasks (no aggressive timeouts on forms)
• Nothing should flash more than 3 times per second (seizure risk)
• Pages need clear navigation: headings, skip links, descriptive page titles
• Touch targets on mobile must be at least 24×24 pixels

Understandable

Content and interface behavior must be clear and predictable.

What this means for your website:

• The page language must be declared in the HTML (lang="en")
• Forms must provide clear error messages and suggestions for correction
• Navigation must be consistent across pages

Robust

Your content must work with current and future assistive technologies.

What this means for your website:

• Valid, well-structured HTML
• ARIA attributes used correctly (or not at all — bad ARIA is worse than no ARIA)
• Status messages communicated to assistive technologies without requiring a page reload

The 10 most common issues on government websites

After scanning hundreds of municipal websites, these are the issues we see most frequently. The good news: most of them are straightforward to fix.

1. Images without alt text

Found on 90%+ of government sites. A screen reader user encounters an image and hears nothing — or worse, hears the file name ("IMG_4582.jpg"). Add an alt attribute to every <img> tag. For decorative images, use alt="" so screen readers skip them entirely. About 2 minutes per image.

2. Low color contrast

Found on 80%+ of sites. People with low vision, color blindness, or simply reading on a phone in bright sunlight can't read low-contrast text. Aim for at least 4.5:1 for body text. Common offenders: light gray text on white backgrounds, white text on light blue buttons. A CSS change that takes minutes.

3. Form inputs without labels

Found on 70%+ of sites. When a form field doesn't have a proper <label> element, screen reader users can't tell what information to enter. Every <input>, <select>, and <textarea> needs an associated <label> with a matching for attribute. Placeholder text is NOT a substitute for a label.

4. Missing page language

Found on 40%+ of sites. Screen readers need to know what language the page is in to use the correct pronunciation. Add lang="en" to your <html> tag. This is a 30-second fix that affects your entire site.

5. Heading hierarchy issues

Found on 60%+ of sites. Screen reader users navigate by headings — they're like a table of contents for the page. Skipping from h1 to h3, or using headings for visual styling rather than structure, makes navigation confusing. Use headings in sequential order (h1 → h2 → h3). Only one h1 per page.

6. Links with no discernible text

Found on 50%+ of sites. A link that says "click here" or has no text at all gives a screen reader user no context. Make link text descriptive. Instead of "click here," write "view the meeting agenda." For icon-only links, add an aria-label.

7. Missing skip navigation link

Found on 60%+ of sites. Keyboard users must tab through every navigation link on every page before reaching the main content. Add a "Skip to main content" link as the first focusable element on the page. It can be visually hidden until focused.

8. Inaccessible PDFs

Nearly universal on government sites. Government websites are full of PDFs — agendas, budgets, forms, reports. If these aren't tagged and structured properly, screen readers can't read them at all. This is the hardest issue to address. For new documents, create accessible PDFs from the start. For existing PDFs, prioritize the most-used ones.

9. Auto-playing media without controls

Found on 20%+ of sites. Auto-playing audio or video can be disorienting and interfere with screen reader output. Never auto-play audio. If video auto-plays, provide a visible pause button. Better yet, don't auto-play anything.

10. Keyboard traps

Found on 15%+ of sites. A keyboard user tabs into a component and can't tab out — they're stuck. Usually found in embedded maps or modal dialogs. Test all interactive components with keyboard-only navigation. Make sure the Escape key closes modals and focus returns to the triggering element.

What's exempt

The rule includes five limited exceptions. If content qualifies for an exception, it doesn't need to meet WCAG 2.1 AA. But you still have to provide the information in an accessible format if someone requests it.

1. Archived web content. Old content kept purely for reference or research, stored in a designated archive area, not updated since being archived, and created before your compliance date. A 2019 water quality report in your archives section qualifies. Your current budget PDF does not.

2. Preexisting conventional electronic documents. PDFs, Word docs, presentations, and spreadsheets posted before your compliance date — unless they're currently being used to provide information about government services. Your 2018 annual report might be exempt. Your current building permit application form is not.

3. Third-party content. Content posted by someone other than your government — like comments on your social media posts or content on a website you link to (but don't host). Important: third-party tools you use to deliver services (payment processors, form builders) are NOT exempt. Those are your responsibility.

4. Preexisting social media posts. Social media posts made before your compliance date. But all new posts after the deadline must be accessible.

5. Password-protected individualized documents. Documents in a secure portal that are about a specific person, property, or account (like a tax bill in a resident portal).

Don't rely on exceptions as a compliance strategy. They're narrow, require careful documentation, and don't eliminate your obligation to provide accessible information when someone asks for it.

The overlay widget trap

You may have heard of "accessibility overlay" widgets — products like AccessiBe, UserWay, or EqualWeb that promise instant compliance by adding a JavaScript widget to your site.

Do not use these for compliance. Here's why:

The FTC took action. In 2025, the FTC fined AccessiBe $1 million for making false compliance claims. This sent a clear signal that overlays cannot be marketed as a compliance solution.

Overlays don't fix your code. They add a cosmetic layer on top of your website. The underlying accessibility problems — missing alt text, broken heading structure, unlabeled forms — remain in your source code. Screen reader users often find that overlays actually create new barriers.

The disability community opposes them. The National Federation of the Blind, the overlay fact sheet signed by hundreds of accessibility professionals, and multiple DOJ settlements have all expressed opposition to overlay-based compliance strategies.

Courts don't accept them as proof of compliance. Multiple lawsuits have been filed against companies that used accessibility overlays. Having an overlay installed has not been accepted as a defense.

What actually works: Fix the source code. Use automated scanning to find issues, then make the actual HTML, CSS, and content changes needed. This is what GovAccess helps you do — we identify the specific issues and tell you exactly how to fix each one.

How much compliance costs

The cost depends on your website's size and current state. Here's a realistic breakdown for a typical municipal website:

Small city website (20-50 pages)

• Automated scanning and monitoring: $79-$149/month
• Developer time for remediation: 15-40 hours total
• Estimated total first-year cost: $2,000-$5,000

Medium city website (50-200 pages)

• Automated scanning and monitoring: $149-$299/month
• Developer time for remediation: 40-100 hours total
• Possible manual audit for complex sections: $1,500-$3,000
• Estimated total first-year cost: $5,000-$15,000

Large city website (200+ pages, multiple departments)

• Enterprise scanning platform: $300-$1,000/month
• Developer and content editor time: 100-300 hours total
• Manual audit: $3,000-$5,500
• Estimated total first-year cost: $15,000-$50,000+

Where to find budget

• ARPA funds — Many municipalities are using COVID relief funds for digital infrastructure improvements
• IT modernization grants — Frame accessibility as infrastructure improvement
• DOJ grants — Specifically for ADA compliance
• State technology funds — Check your state's programs
• Risk management budget — Position as lawsuit prevention (the cost of one ADA lawsuit vastly exceeds the cost of compliance)

What you probably don't need

• A $10,000+/year enterprise platform (if you're under 200 pages)
• A full manual audit before you've fixed automated findings (fix the easy stuff first)
• An overlay widget (see above — these create legal risk, not compliance)

Step-by-step compliance roadmap

Phase 1: Assessment (Week 1-2)

Inventory your digital assets. Make a list of everything: your main website, department microsites, mobile apps, online forms, PDF documents, embedded third-party tools. You can't fix what you haven't cataloged.

Run an automated scan. Start with your homepage and your 10 most-visited pages. An automated scan catches about 30-40% of WCAG issues — but it catches the most common and impactful ones.

Designate an ADA coordinator. If your municipality has 50 or more employees, you're already required to have one. Make sure they have the authority and resources to drive this project.

Phase 2: Quick wins (Week 2-4)

Fix the issues that affect the most pages and require the least effort:

• Add the page language attribute (lang="en") — affects entire site, 30 seconds
• Fix color contrast in your CSS — affects entire site, 1-2 hours
• Add alt text to images — 2 minutes per image
• Label form inputs — 1-2 minutes per field
• Add skip navigation link — 30 minutes, affects entire site
• Fix heading hierarchy — varies by page

These quick wins typically resolve 40-60% of the violations found in an automated scan.

Phase 3: Deeper remediation (Week 4-8)

• Fix keyboard navigation issues
• Address ARIA usage problems
• Remediate the most-used PDF documents
• Test third-party integrations (payment portals, form builders)
• Add captions to videos

Phase 4: Policy and ongoing

• Publish an accessibility statement on your website
• Update procurement contracts to require WCAG 2.1 AA from vendors
• Train staff who create content (even just adding alt text to images)
• Set up monthly monitoring to catch regressions
• Document everything — scan reports, remediation work, training records

This documentation is your proof of good faith effort. Courts and enforcement agencies consistently treat organizations better when they can show they're actively working on accessibility, even if they haven't achieved full compliance.

What happens if you don't comply

DOJ enforcement

The Department of Justice can initiate investigations, typically triggered by complaints. These often result in consent decrees requiring extensive remediation under federal oversight — with strict timelines and regular reporting. Federal penalties can reach $75,000 for a first violation and $150,000 for subsequent violations.

Private lawsuits

Over 8,600 ADA-related lawsuits were filed in 2025. While most target private businesses under Title III, Title II litigation against government entities is growing. Lawsuits typically result in legal fees, settlements, and court-ordered remediation.

State enforcement

Several states have their own accessibility requirements. Colorado's HB 21-1110 includes monetary penalties. California's AB 434 requires biennial accessibility certifications for state agencies. More states are following.

Practical consequences

Beyond legal risk, inaccessible websites simply don't serve all residents. When someone can't pay their water bill online because the payment form isn't labeled, or can't read the city council agenda because the PDF isn't tagged — that's a failure of public service.

FAQ

Q: We redesigned our website recently. Does that mean we're compliant?

Not necessarily. A modern design doesn't guarantee accessibility. Many popular website templates and CMS themes have accessibility issues. The only way to know is to test — run a scan and check.

Q: Can we just hire someone to fix everything?

Yes, but choose carefully. Look for firms that do actual code remediation, not overlay installations. Ask for WCAG 2.1 AA conformance specifically. Get references from other government clients. And remember — even after a one-time fix, you need ongoing monitoring because content changes introduce new issues.

Q: Is WCAG 2.2 required?

No. The DOJ rule specifies WCAG 2.1 Level AA. WCAG 2.2, published in October 2023, includes 9 additional success criteria. It's backward compatible — meeting 2.2 automatically satisfies 2.1. Some organizations choose to target 2.2 for future-proofing, but it's not legally required under the current rule.

Q: What about mobile apps?

The rule covers mobile applications too. The same WCAG 2.1 AA standard applies. If your municipality has an app for bill payments, service requests, or public information, it needs to be accessible by the same deadline.

Q: We use a CMS vendor — isn't that already accessible?

Your CMS or platform provider may offer an accessible template, but you're responsible for the content you put into it. Images without alt text, improperly structured headings, inaccessible PDFs — these are content issues, not platform issues. Check with your vendor about their WCAG conformance and get it in writing.

Q: How do automated scans compare to manual audits?

Automated scans catch about 30-40% of WCAG issues — primarily the technical, machine-detectable ones like missing alt text, contrast failures, and missing labels. The remaining 60-70% require human judgment (is the alt text actually meaningful? Is the reading order logical? Can a real person complete this form with a screen reader?). Start with automated scanning to fix the easy wins, then consider a manual audit for critical sections of your site.

Q: What is a "proof of good faith effort" and do I need one?

It's documentation showing that your municipality is actively working toward compliance — scan results, remediation plans, records of fixes made, staff training, and budget allocations. While not a legal shield, courts and enforcement agencies consistently treat organizations that demonstrate good faith effort more favorably than those that did nothing. GovAccess generates this report automatically with every scan.

For a complete accessibility audit of your full website with prioritized fix instructions and a proof-of-effort PDF report, start a free 14-day trial of GovAccess — built specifically for local governments at a price that fits your budget.

Disclaimer: This article is for informational purposes only and does not constitute legal advice. Consult with your municipality's legal counsel for guidance specific to your situation.