Under the Department of Justice's ADA Title II rule, a chatbot on a town or county website is part of that government's web content, so it needs to meet WCAG 2.1 Level AA by April 26, 2027 for governments serving 50,000 or more people, or April 26, 2028 for smaller governments and special districts.
Those dates are later than the ones many towns first heard. The rule was published on April 24, 2024 with earlier deadlines, and in April 2026 the Department of Justice extended them. If your accessibility plan was built on the old dates, you have more time, but not a reason to stop.
This post covers what the rule requires, why third-party tools such as chat widgets count, and the questions to ask any vendor before you add one to the town website. It is a practical summary, not legal advice. Your town counsel and your state's guidance should have the final word.
What the rule requires
The DOJ's Title II rule on web content and mobile apps applies to state and local governments, including towns, cities, counties, public schools and special districts. According to the ADA.gov fact sheet on the rule, the technical standard is the Web Content Accessibility Guidelines (WCAG) version 2.1, Level AA.
WCAG 2.1 is published by the World Wide Web Consortium. Level AA is the middle of its three levels and covers things such as:
- text alternatives for images and other non-text content;
- enough color contrast between text and background;
- full use with a keyboard, without a mouse;
- a visible focus indicator, so keyboard users can see where they are;
- content that reflows on a small screen or at high zoom without horizontal scrolling;
- status messages that screen readers announce without moving the user's focus;
- clear labels and instructions for forms and inputs.
The rule covers web content a government provides or makes available, directly or through contractors and vendors. It also covers mobile apps.
The compliance dates
Here is what ADA.gov says today, after the April 2026 extension:
| Government size (total population) | Compliance date |
|---|---|
| 50,000 or more | April 26, 2027 |
| Under 50,000 | April 26, 2028 |
| Special district governments | April 26, 2028 |
ADA.gov states that on April 20, 2026, the Federal Register published the Department's interim final rule extending these dates. For most governments, ADA.gov says the population figure comes from 2020 U.S. Census Bureau data, and it is the population of the whole jurisdiction, not the size of the department that runs the website.
ADA.gov also notes that governments must keep meeting WCAG 2.1 Level AA after these dates. Accessibility is an ongoing requirement, not a one-time project. And the general ADA duties of effective communication, reasonable modifications and equal opportunity apply now, regardless of the web rule's dates.
Why a chatbot counts
It's tempting to think of a chat widget as someone else's software that happens to appear on your site. The rule doesn't see it that way.
The fact sheet lists a small number of exceptions, including archived content, some older documents, and content posted by third parties such as members of the public. That third-party exception does not cover content posted by the government, its contractors or its vendors. A chatbot the town chooses, configures and places on its website is provided through an arrangement with a vendor. The safe assumption is that it is covered.
The DOJ's first-steps guide for the rule makes the same point: your public entity is still responsible for the accessibility of its web content when a vendor or contractor provides it.
That applies to the widget itself (the button, the chat window and the controls) and to what it produces (the answers and any links or documents it serves). An accessible chat window that links visitors to a scanned, inaccessible PDF has only solved half the problem.
What makes a chatbot accessible in practice
A chat widget has a few accessibility problems that ordinary web pages don't. These are the areas to test.
Keyboard use
A person should be able to open the chat, type a question, read the answer, follow links and close the window using only a keyboard. Focus should move into the window when it opens and return to the button when it closes. Nothing should trap focus.
Screen reader announcements
New messages appear without a page reload. A screen reader user needs them announced, without the reader jumping around unexpectedly. WCAG 2.1 added a success criterion for status messages that addresses this.
Contrast, zoom and reflow
The chat button and message bubbles often use brand colors. Check contrast for text and controls. At 200% zoom and on a narrow phone screen, the window should remain usable and should not cover content the user can't dismiss.
Labels and plain language
The text box, send button and close button need accessible names. Answers should be written in plain language and should not depend on color or position to make sense.
Timing and motion
Avoid session timeouts that erase a conversation without warning, and avoid animations that can't be paused.
An alternative path
Even an accessible chatbot shouldn't be the only way to reach the town. Keep phone, email and in-person options visible, and make sure the chatbot can point people to them.
Questions to ask vendors
The DOJ's first-steps guide describes practices some governments have found helpful, such as requiring vendors to describe how accessible their product is, asking for contract warranties that the product meets specific technical standards, not letting vendors disclaim those warranties, and requiring indemnification for breaches. The Department does not endorse any particular approach, so review contract language with your counsel. Before you sign, ask:
- Which standard do you test against, and how? Ask for WCAG 2.1 Level AA specifically, and ask whether testing is automated, manual, or both.
- Has an independent audit been done? If yes, ask for the report or an accessibility conformance report (often called a VPAT). If not, ask when one is planned and what it will cover.
- Can you show keyboard and screen reader use? Ask for a live walkthrough with a keyboard only and with a common screen reader.
- What can we configure, and can our choices break accessibility? Brand colors are the usual risk. Ask whether the tool warns you or prevents low-contrast settings.
- What happens to the content it serves? If the chatbot links to your documents, those documents need attention too.
- How do you handle reported barriers? Ask for a contact, a response time and a process for fixes.
- Will you put accessibility commitments in the contract? Get the answers to the questions above in writing.
Be wary of any vendor who answers with a single word such as "compliant" and nothing else. A credible answer names the standard, the testing method and what is still open.
Where our product stands
We'd rather be precise than reassuring. VisitorDesk.ai, the AI concierge for towns, chambers of commerce and visitor bureaus, is tested against WCAG 2.1 AA with automated accessibility checks, and a formal audit is pending. We don't claim more than that, and towns should weigh it alongside their own testing and their counsel's advice.
On the content side, it answers from the town's own website pages, FAQs, documents and seasonal notices, and links back to the source. It answers in plain sentences, and visitors can ask in their own language. It does not process permits, payments, utility billing or records requests, and it has no connection to town systems.
For a broader look at where chatbots help town hall and where they don't, read AI for local government and how small towns handle seasonal visitor questions.
A short plan for the next 18 months
- Confirm your date. Check your jurisdiction's total population and whether you are a special district.
- Inventory third-party tools. List every widget, form, calendar, map, payment page and chatbot on your site, and who provides each.
- Ask every vendor the same questions. Use the list above and keep the answers on file.
- Fix your own content. Start with the most-used pages and documents people need to apply for or use services.
- Publish an accessibility contact. Give people a way to report barriers and get help another way.
- Re-test after changes. New features, new brand colors and new content can all introduce problems.
If you are weighing a chatbot as part of that plan, our page for local government explains how VisitorDesk.ai fits a town website, and how VisitorDesk.ai works covers setup.
