Skip to content

Test the chat window as part of the website.

Use this practical integration checklist alongside your broader accessibility review. Record the browser, device, and assistive technology you use.

How should I test a chatbot for accessibility?

Test the installed chatbot within its host page using a keyboard, screen reader, zoom, narrow layouts, increased text spacing and visual preferences. Include loading, errors, long replies and live handoff. Automated scans alone do not establish conformance.

First-party product guidance. How we maintain these guides · Report a correction

Start with the keyboard.

Use Tab to reach the launcher and confirm that focus is visible. Open the assistant, move through the controls, enter a question, and send it without a pointer.

Close the assistant and check where focus returns. Try Escape, and verify that opening the panel has not made important page controls impossible to reach.

  • The launcher has a useful accessible name
  • Focus is visible at every step
  • Controls work without a mouse
  • Closing the panel restores a sensible focus position

Listen to the conversation.

With a screen reader, inspect the launcher, panel, input label, and send button. Submit a question and listen for the new response. The experience should make sense without having to visually locate each new message.

Check that long replies, errors, and loading states do not create repetitive or confusing announcements. If you find a problem, include the exact browser and screen reader combination in your report.

Check zoom, narrow screens, and other overlays.

Enlarge text and test browser zoom. Use a narrow viewport and confirm that the input and controls remain usable without the page developing unnecessary horizontal scrolling.

Inspect interactions with sticky navigation, cookie controls, other widgets, and the on-screen keyboard. A fixed launcher should not prevent a visitor from reaching the content beneath it.

If you customize the chatbot, test the saved palette in the installed widget. Include label visibility, contrast warnings, keyboard access and focus indicators.

Include motion and realistic content.

Enable reduced motion and confirm that optional movement is reduced. Test short answers, long answers, an unavailable response, and a request for human attention.

This checklist supports a focused integration review. It is not a completed WCAG conformance assessment; evaluate the full website and document any remaining issues.

Record reproducible findings.

For each issue, record the page address, browser and version, assistive technology, steps, expected behaviour, and observed result. Describe the user task that was blocked rather than reporting only an automated score.

Check the widget together with cookie banners, navigation drawers, sticky contact buttons, and other content on the host page. Test keyboard focus after opening and closing those elements in different orders. An isolated widget check cannot establish the accessibility of the complete website.

If dictation is enabled, test granting and denying microphone permission, stopping a recording, editing the returned text and continuing by typing. Make sure recording and transcription status are understandable without relying on the microphone icon alone.

A practical review record
JourneyCheckRecord
Open and close the assistantKeyboard operation and visible focusWhere focus starts, moves, and returns.
Send and receive a messageLabels, status updates, and reading orderWhat the screen reader announces and when.
Read at increased zoomReflow, readable content, and reachable controlsZoom level, viewport, and any overlap.
Recover from an errorA clear message and usable retry routeWhether the visitor understands what to do next.

See what your website can answer.

Try a sample, review the result, and decide what comes next.