There is no ADA compliant chatbot you can buy off a shelf — nobody certifies one, and the Americans with Disabilities Act contains no technical standard for web content at all. What exists is WCAG 2.1, and three of its criteria do nearly all the work on a chat widget: a keyboard user has to be able to get back out of the panel, every control has to announce what it is, and each new reply has to be announced without stealing focus. Most widgets on small-business sites fail at least one, and you can find out which in ten minutes without buying anything.
If you are still deciding whether to put a bot on the page at all, whether a chatbot is worth it settles that first; if you have decided, the install walkthrough covers the mechanics and what one costs to run covers the money. This post is only the accessibility question: what the standard asks of a chat widget, how to test yours, and when the honest answer is to fix something else first.
What an ADA compliant chatbot actually is
Two facts sit underneath the phrase, and they pull in opposite directions. The first is that there is no federal checklist: the Department of Justice’s own web accessibility guidance at ada.gov says plainly that “The Department of Justice does not have a regulation setting out detailed standards” for web content. Nobody inspects a chat widget and blesses it, so a vendor selling an “ADA certified” chatbot is selling a phrase.
The second is that no standard is not the same as no obligation: the same guidance states that “the Department has consistently taken the position that the ADA’s requirements apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web.”
What fills the gap is the Web Content Accessibility Guidelines, published by the World Wide Web Consortium. WCAG 2.1 at Level AA is the benchmark audits, procurement questionnaires and settlement agreements converge on. It is a technical standard rather than a statute, and nothing here is legal advice — if a demand letter has already arrived, that is a conversation for a lawyer, not a chatbot vendor.
The three success criteria that decide a chat widget
A full audit works through all seventy-eight of WCAG 2.1’s success criteria. A chat widget is one self-contained piece of scripted interface, and three of them account for most of what goes wrong inside it.
2.1.2 No Keyboard Trap (Level A): “If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.”
This is the failure that ends the visit: the panel opens, focus lands inside it, and Tab cycles forever between the message box and the send button, leaving someone who does not use a mouse stuck in your sales tool. Escape should close the panel and hand focus back to the launcher.
4.1.2 Name, Role, Value (Level A): “For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.”
Read the parenthetical: components generated by scripts. That is precisely what a chat bubble is. A round button carrying a speech-bubble icon and no accessible name is announced as “button” and nothing more. Launcher, panel and close control each need a name, and open-or-shut has to be exposed in markup rather than merely drawn.
4.1.3 Status Messages (Level AA): “In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.”
This is the criterion specific to conversation. A reply appearing in the transcript is a status message: if it is not announced, a screen-reader user sits in silence while the answer sits visible on screen; if it is announced by moving focus, their reading position is yanked away every time the bot speaks.
The ten-minute test, run with the mouse unplugged
No tool and no consultant required. Unplug the mouse and work through this:
- Tab to the launcher. It should take focus with a visible focus ring.
- Open it with Enter, then Space. Both work on a real button; if only a click opens it, the launcher is a styled div.
- Check where focus went. It should move into the panel; if it stays behind, the next Tab press sends the user somewhere invisible.
- Tab through and keep going. You should leave the panel; cycling back to the message box forever is 2.1.2, and it is the one to fix first.
- Press Escape. The panel should close and focus return to the launcher.
- Zoom to 200%. The panel should still fit and scroll without burying the page.
- Turn on the screen reader you already have — VoiceOver on a Mac, Narrator on Windows — and send one message. Listen for whether the reply is read out, and whether it interrupts you.
Write down what happened at each step; that list, not a vendor’s marketing page, is what you take into the next conversation. Nearly all of it is the widget’s own code, which makes it the vendor’s to fix rather than yours, and the failures recur: auto-open on load, an icon-only launcher with no accessible name, focus that never enters the panel or never returns, a typing indicator wired as a repeating live region, and a session timeout that silently clears the transcript.
The half that is your content, not the vendor’s code
A conformant widget can still be unusable because of what you put inside it. That part is yours:
- Never write an instruction that depends on sight or colour — “click the green button on the right” is useless to the people who most need the answer. Name the thing and link it.
- Never make the chat the only way to reach you. A phone number and an email address in plain text on the page do more for accessibility than any widget setting, and they cost nothing.
- Keep the escalation path one step away, because the visitor most likely to be defeated by the interface is also the one most likely to need a human.
What to ask a vendor before you sign
- “Can you send me your Accessibility Conformance Report or VPAT?” Ask for the document, not a yes. Read which WCAG version and level it claims, then read the exceptions — that is where the real answer lives.
- “Can a keyboard user leave the panel without closing the tab?” Name 2.1.2 and ask them to describe the behaviour.
- “How are incoming messages announced to a screen reader?” A vendor who has done the work mentions live regions unprompted.
- “Who fixes an accessibility defect, and in what timeframe?” Get that into the contract, not the sales call.
- “Does the widget auto-open, and can I turn it off?” If it cannot be turned off, that alone is a reason to walk.
A vendor with no conformance report is not disqualified — plenty of good small tools have never written one — but the testing is then yours to do.
When this is the wrong call
If the rest of the site fails the basics, fix the site first. A conformant chat panel bolted to a page with unlabelled forms, images without alt text and a menu that cannot be opened by keyboard has improved nothing that matters, and that money belongs with an independent audit rather than with us. Be equally sceptical of overlays promising compliance in one line of JavaScript: an overlay sits on top of your page and does not rewrite the widget’s own markup, so the three criteria above are untouched by it.
If a demand letter or complaint has already arrived, start with a lawyer. Swapping vendors mid-dispute changes the evidence and rarely helps; get advice on your exposure, then remediate in the order it sets.
If your live-chat tool already ships a conformance report and your team can configure it, keep it. Ask that vendor what you already pay for before buying a parallel system from anyone, us included — replacing a tool that passes with one that markets better is a net loss.
If nobody can staff the handoff, do not add the widget. A panel that collects a question and never answers it is worse than none, and worst for the visitor who had the hardest time using it. If the choice between a bot and a staffed inbox is still open, settle that first.
What it costs
Our pricing is public: the 24/7 AI Receptionist is $497 to set up and $497 per month, and accessibility is not a line item on top of that — the behaviour above either works or it does not, and if it does not, that is ours to fix. What we do not quote for is an independent audit of your site, because we should not be grading our own work.
The order that works: run the keyboard test today and write down every failure, send that list to the vendor with the conformance-report request, turn auto-open off while you wait, put a phone number and an email address on the page in plain text, and book an independent audit of the whole site. If you would rather run that with someone, book a call and we will start with the test rather than the pitch; our services and how we work pages cover the rest.
Frequently asked questions
Is there such a thing as an ADA certified chatbot?
No. There is no certifying body for web content, and the Department of Justice’s guidance states that it does not have a regulation setting out detailed standards. What a serious vendor can give you is a conformance report saying which WCAG criteria their widget meets and where it falls short.
Does WCAG 2.1 Level AA apply to my business by law?
WCAG is a technical standard published by the W3C, not a statute. It matters because it is the benchmark audits, procurement documents and settlements use in the absence of a federal one. Whether the ADA applies to your business is a question for a lawyer.
Will an accessibility overlay make my chatbot compliant?
An overlay does not change the widget’s internal markup, so a keyboard trap inside the panel stays a keyboard trap. Test the widget itself before assuming any script has fixed it.
Do I still need the chat to be accessible if I publish a phone number?
Yes, and publish the phone number anyway. An alternative route is valuable, but it does not license the panel to trap a keyboard user or stay silent when a reply arrives.
How do I test my chatbot without spending anything?
Unplug the mouse, work through the seven steps above, then turn on the screen reader already on your computer and send one message. That finds the failures that matter most, and it costs a morning.
The bottom line
“ADA compliant chatbot” is a phrase with no certificate behind it, but the thing it points at is real and testable. Three criteria carry most of the weight: let a keyboard user out, tell assistive technology what each control is, and announce replies without hijacking the cursor. Test yours this week with the mouse unplugged and take the failures to whoever built it. What the bot has been given to read decides whether its answers are worth hearing; this decides whether anyone can hear them.