Sooner or later, a chatbot vendor will tell your district that its product is “ADA compliant.” It sounds like the answer to a question every technology director is now being asked. It isn’t, and knowing why will save you from buying a promise when you need proof.
Start with what the law actually requires. In April 2024, the U.S. Department of Justice finalized a rule under Title II of the Americans with Disabilities Act that requires state and local governments, public school districts included, to make their websites and mobile apps meet WCAG 2.1 Level AA. In April 2026, the department pushed the deadlines back a year. The standard didn’t change; only the dates did. Districts serving areas with 50,000 or more people now have until April 26, 2027, and smaller ones have until April 26, 2028. One detail catches many districts off guard: the deadline depends on the population of the area the district serves, not on enrollment. A district with 4,000 students in a city of 60,000 is on the 2027 clock.
The second detail matters even more for chatbots. The rule covers content a district provides directly or through a contract, license, or other arrangement. The Justice Department’s guidance on the web rule says that tools a government places on its site, such as calendars, maps, and payment systems, generally have to meet the standard too, even when an outside company built them. A chatbot on your homepage is no different. If your district put it there, families experience it as your website, and the obligation is yours.
That is why “ADA compliant” is the wrong thing to buy. Compliance belongs to the district and to its whole website, not to a single product. There is no federal certification that stamps a tool as ADA compliant. What a vendor can do is build to the technical standard, test against it, and show you the results. A claim without that evidence is marketing, and regulators have noticed. In 2025, the Federal Trade Commission ordered accessiBe, a company selling an AI accessibility tool, to pay $1 million, in part over claims that its product could make any website WCAG compliant.
Chatbots deserve extra scrutiny because they do the things accessibility standards are hardest on. A static web page sits still. A chatbot pops open, takes over the keyboard, adds new messages without reloading the page, switches languages, and may end the conversation after a set time. Each of those is a place where a family can get stuck. Picture a parent who uses a screen reader asking what time school starts. If the widget doesn’t announce new replies, the answer appears on screen and the parent hears nothing. A parent who navigates by keyboard may open the chat and find no way to close it. A grandparent who zooms to 200 percent may lose the send button off the edge of the screen. Brand colors that look fine in a style guide can turn reply text into pale blue on white that many readers can’t make out.
None of these failures shows up in a sales demo, and few of them show up in an automated scan alone. So instead of asking whether a chatbot is ADA compliant, ask for evidence you can check.
Ask for the vendor’s VPAT, the Voluntary Product Accessibility Template. A completed one is called an Accessibility Conformance Report, and it walks through each WCAG success criterion with a result and an explanation. Confirm it covers WCAG 2.1 Level AA, since that is the standard the rule names, and check the date. A report from three versions ago tells you little about what’s running today.
Read the partial results, not just the summary. A report that marks every criterion “Supports” deserves a closer look, not less of one. Real products have edge cases, and a vendor who documents them plainly is telling you how carefully they looked.
Ask how the testing was done. Automated tools catch some problems, like missing labels and low contrast. They can’t tell you whether a screen reader user can follow a conversation. You want to hear that people tested with a keyboard alone and with at least one screen reader.
Ask what the report covers. The widget families use and the dashboard your staff use are different products, and a report on one doesn’t speak for the other.
Then spend five minutes testing it yourself, the same way you’d run the front office test on its answers. On a page where the chatbot is installed, put your mouse aside, press Tab until the chat button is highlighted, and press Enter. Type a question, send it, and press Escape to close the chat; focus should land back on the chat button. Turn on VoiceOver on a Mac (Command+F5) or NVDA on Windows and listen for the reply when it arrives. Zoom your browser to 200 percent and make sure you can still type and send. If any of that fails, you’ve learned more than a sales call will tell you.
Remember, too, that the chatbot is only part of the picture. It answers from your district’s own pages and documents, and those need to be accessible as well. A widget built to the standard that links families to a scanned, untagged PDF has only moved the barrier one click away.
We built the AskK12 widget to meet WCAG 2.1 AA, and we publish our VPAT on our accessibility page, including the one criterion where the widget only partially supports the standard and why. That is the level of detail every district should expect from every vendor on its website, including us. If you’re comparing options, the AskK12 features page shows what the widget does, and the report shows how it was tested.
The deadlines are real, and the questions are fair. A vendor that is ready for them will answer quickly and in writing.