AI for Small Business

Chatbot Accessibility Checklist: Six Checks for Your Website Chat

By Dante AIOctober 10, 20266 min read

TL;DR: A chat window that works with a mouse on a large screen can still block keyboard users, screen reader users and people on small screens. This chatbot accessibility checklist gives you six observations to make on the chat you actually publish: keyboard operation, visible focus, named controls, announced replies, narrow screens with larger text, and a usable way forward. Tick only what you observed working, fix or test the first check you did not observe, then test again. It is a repair list, not a compliance certificate.

Your chat window may look perfectly sensible to someone using a mouse on a large screen. That is one way to use a website. It is not everybody's way.

Chatbot accessibility is about whether people can operate the chat, understand its messages and recover when it cannot help. This checklist helps you record six observations about the chat you actually publish and turn the gaps into a repair list. It does not scan your website, and it does not certify compliance.

Test the chat you actually publish

Use the live website, not a settings preview. Write down the device, the browser and, where relevant, the assistive technology you used. Ask dummy questions and never type private customer information. In the tool below, tick a check only when you observed it working on the path you tested. Leave a check unticked if it failed or if you could not test it. Guessing is not evidence.

The MITRE Chatbot Accessibility Playbook gives a broader design and assessment framework. These six checks are a smaller starting point. A full evaluation may need specialist testing and the participation of people who use assistive technology every day.

1. Open, use and close it with the keyboard

Put the mouse aside. Move through the page with Tab, open the chat and type a question. Check that you can reach every control, send the message and close the window. Note any point where you get stuck.

W3C's keyboard guidance explains why functionality needs a keyboard route. This checklist records the one path you tested; one successful path does not make the whole website accessible.

2. Follow the focus

As you move between controls, can you see which one is active? When the chat opens or closes, does focus land somewhere sensible? A visitor should not have to hunt through the whole page to pick up where they left off. Record the step where focus disappears or jumps.

3. Check that controls are named

With a screen reader running, move to the launcher, the message box, the send control and the close control. Is each one announced with a clear purpose? An attractive icon is not evidence that assistive technology can identify it. If you have not run this test, leave the check unticked.

4. Check that new replies are announced

Send a test question. Can a screen reader user tell that a reply has arrived, without losing their place? Do not assume that a reply people can see is also communicated to assistive technology. W3C's status-message guidance explains the difference between a visible change and the way it is exposed to assistive technology.

5. Try a narrow screen and larger text

Check that the message box, the replies and the close control stay usable on a narrow screen and with text enlarged. Look for cut-off text, controls pushed out of reach and a chat window that covers the rest of the task. Record the configuration you used and what failed, not just a screenshot of the default desktop view.

6. Find another way forward

Ask a question the chat cannot answer. Can the visitor understand the next step and reach a usable alternative, such as a contact form or a person? A listed email address still has to be readable and reachable. Do not assume a working handover from a label alone.

Use the result as a repair list

The tool counts the checks you observed working and lists the rest as the things to fix or test first. The result is a repair list, not an accessibility rating or a legal opinion. Passing these six observations does not establish full WCAG conformance.

A hypothetical example: the launcher works with a mouse, but keyboard focus never reaches it. Record that failed path, have the interface fixed and run the same test again. What you need is a usable path, not a green badge.

For the wider rollout, see how to add AI chat to your website, and for what should happen when the chat cannot help, choosing a chatbot with human handover. Whichever chat you use, run the same six checks on the interface you publish, and again after any change. This article makes no claim that any particular Dante configuration has passed them.

Chatbot accessibility: six checks on your live chat

Without the interactive tool, count the checks you observed working. Each one is worth about 17 points out of 100. An unticked check means not observed: it may have failed or not been tested yet, so fix or test it first.

Frequently asked questions

Does passing these six checks make my chatbot WCAG compliant?

No. The checks cover a small set of common problems on one tested path. Full conformance needs a wider evaluation, ideally including specialist testing and people who use assistive technology.

Does this tool scan my website?

No. It records what you observed when you tested your own chat by hand. Nothing is scanned or sent anywhere.

What if I cannot use a screen reader?

Leave checks 3 and 4 unticked and treat them as untested, not passed. Free screen readers come with most operating systems, or you can ask someone who uses one every day to help.

Why include a way forward when the chat cannot help?

A chat that answers well but leaves a visitor stuck when it cannot answer still blocks them. Check that the next step is clear and actually reachable.

How often should I run the checks?

After any change to the chat window, its position on the page or the website theme, and whenever you change chat provider.

Start free