ADA Title II Website Accessibility: What the 2027 and 2028 Deadlines Mean for Agencies

In April 2024 the U.S. Department of Justice published a final rule under Title II of the Americans with Disabilities Act that, for the first time, sets a specific technical standard for state and local government websites and mobile apps: WCAG 2.1 Level AA. In April 2026 the Department extended the compliance dates by one year. This article explains what the rule requires, who has to comply and when, and what an agency can do now so the deadline is not a scramble.

Who has to comply, and by when

The rule applies to state and local governments and the services, programs, and activities they offer online, including content provided by contractors and vendors on the entity’s behalf. Compliance dates depend on the population of the jurisdiction:

The new dates come from an interim final rule the Department published on April 20, 2026. The Department also said it may propose substantive changes to the 2024 rule in a separate rulemaking. Until that happens, WCAG 2.1 AA remains the standard, and planning against it is the safe assumption.

What “WCAG 2.1 AA” means in practice

WCAG (Web Content Accessibility Guidelines) is a set of testable success criteria. Level AA is the middle tier, and it is the level most laws and procurement rules reference. In practical terms, a conforming site or app lets people:

• Use every function with a keyboard alone, with a visible focus indicator and no keyboard traps
• Understand pages through a screen reader: images have text alternatives, form fields have labels, and headings and landmarks describe the page structure
• Read text with sufficient color contrast, and zoom to 200 percent without losing content (and reflow to a narrow width without horizontal scrolling)
• Pause, stop, or hide anything that moves, and finish tasks without strict time limits
• Understand and recover from form errors, with errors identified in text
• Watch prerecorded video with captions, and get equivalent information from audio-only content

Federal agencies have a parallel obligation under Section 508 of the Rehabilitation Act, which also incorporates WCAG success criteria. Vendors who sell to both levels of government usually document conformance in an Accessibility Conformance Report (ACR) based on the VPAT template.

What is covered, and what is not

The rule covers web content and mobile apps that a public entity provides or makes available, directly or through contractual, licensing, or other arrangements. That includes online applications, payment portals, permit and license systems, meeting agendas and minutes, maps, and documents posted for the public.

The rule includes a small number of exceptions, each with conditions. They cover archived web content, certain preexisting electronic documents, content posted by third parties who are not acting for the entity, individualized password-protected documents, and preexisting social media posts. Read the conditions carefully before relying on one. For example, a preexisting document is not excepted if people currently use it to apply for or access a service.

Why the extension is not a pause

• The underlying obligation already exists. Title II has required effective communication and equal access to programs for decades. The Department stated that public entities have an ongoing obligation to make their services accessible regardless of the new dates.
• Complaints and lawsuits continue. Residents can still file complaints, and private litigation over inaccessible websites does not wait for a compliance date.
• Remediation takes longer than it looks. Fixing templates is quick. Fixing thousands of documents, third-party portals, and embedded tools takes procurement cycles and budget years.

A practical plan for the next 12 months

1. Inventory what you publish

List every public website, subdomain, mobile app, and third-party system that residents use: payments, permitting, scheduling, GIS viewers, video, and forms. Note who owns each one and whether a vendor controls the code.

2. Get a real baseline

Automated scanners are a good start, but they catch only part of the problem. Keyboard traps, confusing screen reader output, and unusable forms take a person to find. A useful baseline combines more than one automated engine with manual keyboard and screen reader testing on the most important tasks.

3. Fix problems where they start

Most issues trace back to a handful of templates and components, so fixing those first clears many pages at once. Avoid overlay widgets that add a toolbar on top of the page. They do not repair the underlying code, they can interfere with the assistive technology people already use, and they leave no record of what was found or fixed.

4. Put accessibility in your contracts

Require WCAG 2.1 AA conformance in new solicitations and renewals, ask vendors for a current ACR, and include a remediation obligation and timeline. Content that a vendor provides on your behalf is still your responsibility.

5. Keep it fixed

Sites change every week. Scheduled scans, a periodic manual review, and editor training keep new content from undoing the work. Publish an accessibility statement with a way for people to report barriers, and route those reports to someone who can fix them.

How we help

SiteHatchery builds and tests everything we deliver to WCAG 2.1 AA, and we audit and remediate existing sites and applications. Our accessibility service, Audsey, combines four automated testing engines with keyboard and NVDA screen reader testing, fixes issues in the site’s own code and content, and produces before-and-after reports and VPAT conformance reports for procurement. See Accessibility & Section 508 for details, or contact us to talk through your inventory.

This article is general information, not legal advice. Compliance dates reflect the Department of Justice interim final rule published April 20, 2026. Check the Federal Register and ADA.gov for later changes.