The short answer
Yes, if you run the website of a US state or local government, the Department of Justice web rule sets WCAG 2.1 Level AA as the standard. The deadline depends on population: 26 April 2027 for public entities with a total population of 50,000 or more, and 26 April 2028 for those under 50,000 and for special district governments. This is a readiness guide, not legal advice, so confirm the details for your entity with counsel.
Where the dates come from
Both dates are taken from the ADA.gov fact sheet on the web and mobile app rule, and the documentation of the scanner I read for this article cites the same page: https://www.ada.gov/resources/2024-03-08-web-rule/. Read the original page yourself before you plan a budget around a date. The dates were checked on that page on 30 October 2026 and come from the April 2026 rule that extended the original dates.
A first-pass checklist
- Find out which date applies to you. Use the entity's total population, and write down where the number comes from, for example a census estimate. A county and the school district inside it can fall on different sides of the 50,000 line.
- List your public pages. Start with the ten most visited: home, contact, payments, permits, meeting agendas, the news page.
- Test those pages with a keyboard. Put the mouse aside and press Tab. Can you reach every link and button? Can you see where you are? Can you open and close menus and submit a form?
- Run an automated scan. An automated check tests pages against WCAG 2.1 AA rules and gives you a list of failures per page. It finds only part of what the standard requires, so a clean scan is not a pass.
- Open every PDF you link to. Many public sites publish agendas, minutes and forms as PDFs. A PDF needs tags to be usable by a screen reader, and a scanned image with no text layer is the worst case. Count how many you have.
- Check for exceptions. The rule treats five kinds of content differently: archived content, preexisting documents, third-party content, password-protected documents and preexisting social media posts. Decide which of yours fall in them, and write down why.
- Watch out for overlays. Accessibility overlays, the add-on widgets that promise a fix in one line of code, are not treated as conformance under the rule.
What I would fix first
The pages people use to pay, apply and contact you. Then the documents attached to them. A homepage with perfect scores and an unreadable permit form is still a failure for the person who needs the permit.
Who should own this
Name one person. In most small entities the site belongs to nobody in particular: the clerk uploads agendas, the finance office adds a payment link, a vendor built the theme five years ago. Accessibility work stalls when it belongs to everyone. Give one person the list from step 2, a monthly hour to work through it, and the authority to ask each department to fix its own documents. A short written log of what was tested, when and by whom is also useful if anyone asks how you prepared.
A realistic schedule
If your date is April 2027, today is early November 2026, so you have roughly six months. Spend the first month on the list, the keyboard test and the PDF count. Spend the next three on the payment, application and contact pages and the documents attached to them. Keep the last two for a second test with a person and a screen reader, and for the exceptions list. If your date is April 2028 you have more room, but the PDF count is the same size of job and does not shrink by waiting.
What an automated scan cannot do
It cannot tell you whether the alt text on a photo makes sense, whether a form label tells a person what to type, or whether a screen reader user can finish a payment. A scan is a readiness report, not a conformance certificate. The last step is always a person using the site with a keyboard and a screen reader.
If you would like help reading your own scan, the booking page is /book.