Back to Blog Technology

ADA Title II: Government Website Deadline Is April 26, 2027

The Department of Justice set April 26, 2027 as the compliance date for the largest public entities and April 26, 2028 for smaller ones. Here is what the rule requires and what to do with the time left.

SMRTLVTechnology

On April 26, 2027, state and local governments with a population of 50,000 or more must make their web content and mobile apps meet WCAG 2.1 Level AA. Smaller entities and special district governments have until April 26, 2028. Both dates come from the Department of Justice (DOJ) Title II rule, as extended by one year in April 2026.

This is a federal rule, not a best practice. Non-compliance can lead to complaints, DOJ investigations, lawsuits and court-ordered remediation.

If you run a city website, a county portal, a public school district site, a transit authority page, or any digital property tied to a state or local government entity, this applies to you. The rule was published in April 2024. As of this post's update there are roughly six months left before the first deadline.

What the Rule Actually Says

In April 2024 the Department of Justice published a final rule under Title II of the Americans with Disabilities Act. Title II covers state and local governments — every city, county, school district, public university, transit authority, water district, and public agency in the country.

The rule does one specific thing: it defines what "accessible" means for government websites and mobile apps. Before this rule, the ADA said government services had to be accessible to people with disabilities, but it never specified a technical standard. Courts were left to figure it out case by case. That ambiguity is over.

The standard is now WCAG 2.1 Level AA. That is the Web Content Accessibility Guidelines, version 2.1, conformance level AA. It is published by the World Wide Web Consortium (W3C) and it is the same standard used by the European Union, Canada, Australia, and most of the developed world.

The Deadlines

  • April 26, 2027: state and local government entities with a total population of 50,000 or more.
  • April 26, 2028: entities with a population under 50,000, and special district governments.

Source: the DOJ final rule of April 2024 (28 CFR Part 35, Subpart H) originally set April 24, 2026 and April 26, 2027. On April 20, 2026 the DOJ issued an interim final rule moving both dates back one year, to April 26, 2027 and April 26, 2028. The WCAG 2.1 Level AA standard did not change. The rule has limited exceptions (for example certain archived content) and "fundamental alteration" and "undue burden" defenses, so read the rule text or ask counsel how it applies to your entity. This post is general information, not legal advice.

What Is Covered

The rule applies to all web content and mobile applications that a government entity uses to provide services, programs, or activities to the public. That includes:

  • Your main website
  • Online payment portals (utilities, permits, fines)
  • Meeting agendas and minutes (including posted PDFs)
  • Job application systems
  • Public records portals
  • Park and recreation registration systems
  • Mobile apps
  • Third-party content you embed or link to as part of your services

If a resident needs it to interact with their government, it must be accessible. Period.

What WCAG 2.1 AA Actually Means

WCAG 2.1 Level AA has 50 individual success criteria organized under four principles: Perceivable, Operable, Understandable, and Robust. Here is what that means in plain English, with the specific issues we see on government websites every day.

Every Image Needs Alt Text

Every non-decorative image on your site must have a text description that conveys the same information the image does. A photo of your city council? The alt text should say who is in the photo. A chart showing budget allocation? The alt text (or a nearby data table) must convey the same data. An icon that links to a PDF? The alt text must describe the link destination, not say "icon" or "image." Images with no alt text at all are one of the most common failures on any large site.

Every Form Needs Proper Labels

Every input field in every form must have a programmatically associated label. That means a <label> element with a for attribute that matches the input's id. Placeholder text inside the field does not count. If your online permit application has 30 fields and none of them have proper labels, a screen reader user cannot fill it out. That is a Title II violation.

Color Contrast Must Meet 4.5:1

Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) must meet 3:1. This sounds obscure until you look at how many government sites use light gray text on white backgrounds, or put text over busy photographs without a solid overlay. A contrast checker takes 10 seconds to run. Most government sites have dozens of failures.

Keyboard Navigation Must Work

Every interactive element — links, buttons, form fields, dropdown menus, modal dialogs, date pickers — must be operable using only a keyboard. No mouse required. Many custom JavaScript components (hamburger menus, tabbed interfaces, accordion panels, custom dropdowns) are completely invisible to keyboard users. They press Tab and the focus jumps right past the interactive element. This is one of the most common and most serious accessibility failures we find.

Videos Need Captions

Every video with audio must have synchronized captions. Not auto-generated captions full of errors — accurate captions that convey the spoken content and identify speakers. Every pre-recorded video also needs an audio description track or a text transcript for visual content that is not conveyed by the audio alone. City council meeting recordings, public hearing videos, instructional content — all of it needs captions. Auto-generated captions are a start, but they contain errors and do not identify speakers, so they need a human review.

PDFs Must Be Accessible

This is where the majority of government websites will fail. Most government sites have hundreds or thousands of PDFs: meeting agendas, budgets, reports, forms, policies, ordinances. If those PDFs were created by scanning a paper document, they are images, not text. A screen reader sees nothing. Even PDFs generated from Word or other software often lack proper heading structure, reading order, alt text on images, and tagged table structures. Remediating a backlog of 500+ inaccessible PDFs is the single most expensive and time-consuming part of compliance for most agencies.

Mobile Accessibility Is Required

WCAG 2.1 added specific criteria for mobile: touch targets must be at least 44x44 CSS pixels, content must work in both portrait and landscape orientation, and functionality that uses device motion (like "shake to undo") must have an alternative. If your mobile site has tiny buttons that are impossible to tap accurately, or if your responsive layout breaks accessibility features that work on desktop, you are not compliant.

Where Government Sites Most Often Fall Short

These are the five issues that accessibility testers most often report on large public-sector sites. They are common patterns, not findings about any specific agency.

PDFs Uploaded as Scanned Images

A staff member scans a printed document and uploads the PDF to the website. It looks like a document. It is actually a picture of a document. A screen reader cannot read it. A search engine cannot index it. A user cannot select or copy the text. On sites with a long history, a large share of the PDF library is often scanned and inaccessible.

Custom JavaScript That Breaks Screen Readers

The web developer built a beautiful interactive map, a custom dropdown menu, a tabbed content area, or a modal popup. It looks great. It works perfectly with a mouse. It is completely invisible to screen readers and unreachable by keyboard. Custom interactive components need ARIA attributes (roles, states, properties) and keyboard event handlers to be accessible. Most do not have them.

Videos Without Captions

City council meetings, public hearings, department presentations, promotional videos — uploaded to YouTube or embedded directly, with no captions or only auto-generated captions full of errors. For a Deaf resident trying to follow a public hearing about a zoning change that affects their property, this is not a minor inconvenience. It is exclusion from civic participation.

Color Contrast Failures

Government websites love blue. Light blue text on white backgrounds, dark blue text on medium blue backgrounds, gray text everywhere. Run a large site through a contrast checker and expect failures in navigation, footers and helper text. Navigation links, footer text, form helper text, button labels — all below the 4.5:1 minimum.

Inaccessible Meeting Agendas and Public Documents

The documents that matter most to civic engagement — meeting agendas, budgets, planning documents, public notices — are typically the least accessible. They are posted as untagged PDFs, or as Word documents that were never checked for accessibility, or as scanned images. A resident using assistive technology cannot read the agenda for tonight's city council meeting. They cannot review the proposed budget. They cannot access the public notice about a construction project on their street.

What Happens When You Miss the Deadline

ADA web accessibility complaints and lawsuits have been filed against public entities for years, even without a defined technical standard. The rule now names the standard, which makes it easier to say whether a site meets it.

ADA Lawsuits

Most web accessibility lawsuits have targeted private businesses, but public entities are not immune. Advocacy organizations like the National Federation of the Blind and local disability rights groups regularly file complaints and lawsuits against municipalities with inaccessible websites. Once a compliance date passes, the question for a court is simpler: does the content meet WCAG 2.1 AA or not.

DOJ Enforcement Actions

The Department of Justice can investigate and take enforcement action against any state or local government entity that violates Title II. This can result in consent decrees — court-supervised agreements that require you to remediate your site on a specific timeline, hire accessibility consultants, conduct regular audits, train staff, and report compliance progress. The DOJ sets the terms.

Settlement Costs

A settlement can include damages, plaintiff attorney fees and the cost of the remediation it requires. Amounts vary widely by entity and case, and we have not cited a figure here because we have no verified source for one. Fixing a site on your own schedule is usually cheaper and calmer than fixing it under a legal deadline.

Federal Funding at Risk

Title II compliance is tied to eligibility for federal funding. Agencies that receive federal financial assistance — which includes virtually every city, county, and school district in America through one program or another — can face funding reviews and potential loss of funds for ADA violations. This is the risk that gets the attention of elected officials faster than anything else.

Public Embarrassment

ADA lawsuits are public record. Consent decrees are public record. When your city gets sued because a blind resident cannot pay their water bill online, that makes the local news. When the settlement terms include an admission that your website was inaccessible to people with disabilities, that is not a good look for any elected official. The political cost is real.

The Fix: What It Actually Takes

Accessibility compliance is not a one-time checkbox. It is a process, and it is easier to plan if you start early.

Step 1: Audit

A comprehensive accessibility audit combines automated scanning tools with manual testing by accessibility specialists, including testing with actual assistive technologies (screen readers, keyboard-only navigation, voice control). Automated tools catch about 30-40% of WCAG violations. The rest require human judgment — reading order, meaningful alt text, logical heading hierarchy, usable focus management. The deliverable is a detailed report of every violation, prioritized by severity and page traffic, with specific remediation instructions.

Step 2: Remediation

Effort depends on what the audit finds. A well-built site with minor contrast issues and missing alt text is a small job. An older CMS with thousands of inaccessible PDFs, custom JavaScript components and embedded third-party widgets is a large one. Typical cost depends on the number of pages, documents and systems; we write the scope and price down before work starts. Common remediation tasks include:

  • Adding alt text to all images
  • Fixing color contrast across the entire site
  • Adding proper form labels and error handling
  • Rebuilding navigation and interactive components for keyboard access
  • Adding ARIA attributes to custom widgets
  • Remediating PDF documents (or replacing them with accessible HTML)
  • Adding captions to all video content
  • Fixing heading hierarchy and page structure
  • Ensuring mobile touch targets meet size requirements

Step 3: Ongoing Monitoring

Every time someone on your staff uploads a new PDF, adds a page, embeds a video, or updates content, they can introduce new accessibility violations. Ongoing monitoring includes automated scanning on a weekly or monthly schedule, manual spot checks of new content, and alerts when violations are detected. This is what prevents you from fixing everything once and then slowly drifting back into non-compliance as your site evolves.

Step 4: Staff Training (Included in Any Good Engagement)

The people who create and publish content on your website need to understand accessibility basics: how to write alt text, how to create accessible PDFs, how to use heading levels correctly, how to check contrast before publishing. This is not a full-day workshop. It is 2-3 hours of practical, role-specific training. Without it, your remediation work degrades within months as new inaccessible content is published daily.

Realistic Timeline

As an illustration, here is how a plan could be paced if you start now and aim for the April 2027 date (every entity differs):

  • Now: audit completed, prioritized remediation plan in hand.
  • Next 1-3 months: critical violations fixed (keyboard navigation, form labels, major contrast issues) on the highest-traffic pages.
  • Months 3-5: full site remediation, PDF backlog and video captions.
  • Final month: staff training, monitoring in place, final check before the deadline.

The later you start, the less room you have for the PDF backlog, which is usually the slowest part.

Not sure where your public site stands on WCAG 2.1 AA?

We can look at a small site and tell you in writing what we would test and fix. Larger or custom public-sector work gets a written scope and fixed quote before any work starts. We do not hold a VPAT or third-party certification today.

Request a scoped quote

Tell us the site, the number of pages and documents, and your deadline. We reply within 1 business day.