Short answer: if your city, county or school district has a total population of 50,000 or more, your website, mobile apps and posted documents need to meet WCAG 2.1 Level AA by April 26, 2027. Smaller governments and special district governments have until April 26, 2028.
What the rule is
The Department of Justice published its final rule under Title II of the Americans with Disabilities Act on April 24, 2024. It sets a technical standard, WCAG 2.1 Level AA, for the web content and mobile apps that state and local governments provide, including public schools. In April 2026, an interim final rule pushed both compliance dates back by about a year, to the dates above.
Two cautions. A lawsuit filed in May 2026 by the National Federation of the Blind asks a court to undo that extension, and the Department has said it may make further changes, so check ADA.gov for the current dates. And the new dates don't pause the ADA itself: you already have to communicate effectively with residents with disabilities, for example by providing an accessible version of a document when someone asks.
Which deadline is yours
- Population 50,000 or more: April 26, 2027.
- Population under 50,000: April 26, 2028.
- Special district governments (for example, many water, fire or library districts): April 26, 2028.
Population means the total population from the 2020 Census, not the number of people you serve. A department or office that's part of a larger government, such as a city library or police department, uses the population of the government it belongs to. School districts follow their own rule: a city school district uses the city's population, a county school district uses the county's, and an independent school district uses the Census Bureau's Small Area Income and Poverty Estimates for its area. School districts are not special district governments for this rule. (ADA.gov fact sheet)
What it covers
- Your website's pages, including menus, forms and anything your website template adds.
- Documents you post: PDFs, Word files, spreadsheets and slide decks, such as agendas, minutes, budgets, permits and applications.
- Content your vendors or contractors post for you, and tools you add to your site, such as online payments, calendars and maps.
- Mobile apps you provide, including ones a private company runs for you, like a parking payment app.
The exceptions
There are five, and each is narrow. In short:
- Archived web content made before your compliance date, kept only for reference or records, unchanged, and stored in an area clearly marked as archived.
- Pre-existing documents (PDF, Word, Excel, PowerPoint) posted before your compliance date, unless people still use them to apply for, get, or take part in your services.
- Content posted by the public, such as comments, when it isn't posted for you under a contract or other arrangement.
- Password-protected or otherwise secured documents (PDF, Word, Excel or PowerPoint files) about a specific person, their property or their account, such as one resident's utility bill. Account pages shown as web pages, and notices sent to everyone, don't qualify.
- Social media posts made before your compliance date.
Even when something is exempt, you still have to provide it in an accessible way when someone asks. Our guide to the archive and pre-existing document exceptions explains the first two in detail.
A realistic order of work
- Take inventory. List your pages and every posted document, and find out which problems repeat across the site. Most small governments are surprised by how many documents they have.
- Send template problems to your website vendor. Problems in menus, headers, footers, colors and built-in widgets show up on every page, and usually only the vendor can fix them. Ask them to confirm, in writing, that their templates meet WCAG 2.1 Level AA. See who fixes what.
- Fix what residents use now. Start with forms, applications, current agendas, fee schedules and anything people need to get a service.
- Move old records into a labeled archive, if they meet the conditions, so you can focus on current content.
- Make new documents accessible from the start. It's far quicker than fixing them later. See how to make agenda and minutes PDFs accessible.
- Post an accessibility statement with a way to report problems or ask for an accessible copy. It's good practice, and it gives residents a way to reach you before they give up.
- Test your most important pages by hand with a keyboard and a screen reader. Automated checks find only part of the problems. See how to check your site for free.
What won't get you there
Accessibility overlays and widgets, the toolbars that promise to make a site accessible with one line of code, don't fix the underlying problems. In April 2025 the Federal Trade Commission ordered accessiBe to pay $1 million and barred it from claiming, without evidence to back it up, that its automated tool can make any website comply with WCAG or keep it compliant. No automated tool, including ours, can certify that a site complies.
See where your site stands
A free AccessClerk preview checks your first 10 pages in a real browser, lists the documents it finds and checks a sample of your PDFs, in plain English. No sign-up.
Check your site freeMore guides
- How to make agenda, minutes and form PDFs accessible
- Scanned PDFs and screen readers: why copier scans fail and how to fix them
- Do old agendas and minutes need to be accessible? The archive and pre-existing document exceptions
- Website vendor or staff: who fixes which accessibility problems?
- How to check your website’s accessibility for free
This guide is general information, not legal advice. Talk to your attorney about how the rule applies to you.