A customer opens your support widget, tabs through the page, submits a question, and gets an answer they cannot hear or understand. Your chatbot accessibility checklist should catch that before launch. Test two connected things: whether customers can operate the widget, and whether the AI conversation remains understandable and recoverable.
The acceptance rule is simple. Every check needs a tester, a test method, a result, a defect note, and evidence. Evidence can be a screen recording, screenshot, transcript, test log, or retest record. Do not approve a widget because it answered one test question. Approve it when a customer can open, operate, understand, recover, and exit it using the access methods your audience needs.
What a chatbot accessibility checklist should cover
A useful review covers the interface and the conversation. The interface includes keyboard navigation, screen-reader announcements, focus management, readable text, color contrast, text resizing, mobile interaction, meaningful labels, and error states. The conversation includes clear answers, fallback behavior, preserved context, and a usable path to a person.
Use WCAG 2.2 as a reference for the web interface. It provides relevant guidance for keyboard access, focus, contrast, text alternatives, and status messages. It does not, by itself, prove that an AI agent gives useful answers or handles an escalation well.
For each test, record the owner, method, expected result, actual result, evidence, severity, and retest date. This turns an accessibility review into a launch decision instead of a list of reminders.
See the checklist in one conversation
Take a billing question as the test case. A customer opens the launcher with the keyboard, activates it, and lands in the message field. The widget announces that the support conversation is open. The customer types, “Why was I charged twice?” and submits the message.
The widget should announce that the question is processing, then present a response in a reading order that makes sense. The answer should identify what the customer can do next. If the agent cannot answer from the available content, it should say so and offer a usable recovery path, such as asking the customer to clarify the question or request a person.
The accessibility outcome is task completion. The customer can open the widget, enter the question, tell when processing has finished, understand the response, choose the next action, and keep or leave the conversation without losing focus. Repeat the test with a follow-up, such as “The second charge is still pending.” Record the keyboard steps, announcements, transcript, and final result.
Set measurable pre-launch pass criteria
Use acceptance rules that produce a pass or fail result:
| Area | Pass condition | Evidence |
|---|---|---|
| Keyboard operation | The tester can open, operate, submit, request help, close, and return to the page without a mouse or keyboard trap | Screen recording and step log |
| Focus management | Focus moves to a sensible starting point, remains visible, follows a logical order, and returns to the launcher or prior page position after closing | Screen recording or annotated screenshots |
| Screen-reader output | The tester can identify the widget, field, controls, new responses, loading states, errors, and handoff status without searching the page | Test log, transcript, or recording |
| Visual access | Text, controls, focus indicators, icons, and error states remain usable at the required zoom and text size | Screenshots and device details |
| Conversation task | The tester can ask a real support question, understand the response, ask a follow-up, and recover when the agent cannot answer | Conversation transcript |
| Human handoff | The tester can request a person, understand the pending state, retain useful context, and recover when no person is available | Recording and transcript |
WCAG 2.2 is a W3C Recommendation published in October 2023. Success Criterion 1.4.3 specifies a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Success Criterion 1.4.11 specifies 3:1 contrast for meaningful non-text controls and indicators. Success Criterion 1.4.10 addresses reflow at a viewport equivalent to 320 CSS pixels without losing information or functionality.
Last verified: September 2026
These thresholds do not create a pass for the whole AI experience. Every defined customer task must work from start to finish, including recovery from an error and exit from the widget.
Test the widget before testing the answers
Start with the embedded widget before asking it anything. A correct answer does not matter if a customer cannot open the chat, find the text field, read the response, or close the dialog.
Check that the launcher has a useful accessible name, can be reached and activated with a keyboard, and does not trap focus. When the widget opens, focus should move to a sensible starting point and the widget state should be available to the user. Closing it should return the user to a sensible place on the page.
Tab through the message field, send control, suggested replies, status messages, escalation controls, and close control. Focus should remain visible and follow a logical order. Run browser zoom and text-resizing checks for clipped messages, overlapping controls, hidden text, and horizontal scrolling that blocks a task. Check text alternatives for meaningful icons, and confirm that color is not the only way to show an error, selected suggestion, pending handoff, or completed action.
Repeat the sequence on mobile: open the widget, reach the field, type and submit a question, read the response, close the widget, and return to the page. Record the device, operating system, browser, viewport, and result.
Run the same conversation with assistive technology
Use a keyboard-only test first, then repeat with a screen reader. NVDA on Windows and VoiceOver on Apple devices are practical choices when those tools are available to your team.
A new AI response should be announced as a status message without forcing the user to search the page. The loading state should explain that the response is processing. An error should identify what failed and what the user can do next. A handoff update should say whether the request is waiting, accepted, or unavailable.
Test a long response, links, lists, suggested replies, and code or other formatting if the support agent can return them. Check that the user can understand who is responding, what action is available, and whether the conversation is still processing. The MITRE Chatbot Accessibility Playbook self-assessment can help structure the review. Record the device, browser, screen reader, steps, expected result, actual result, and evidence.
Check conversation quality, fallback, and recovery
Use real SaaS support questions from the knowledge base: a straightforward product question, an account or billing question, and a question the trained content cannot answer.
Review each response as a customer. Is it readable? Does it answer the question asked? Is the next action clear? Test unclear input, misspellings, empty submissions, repeated questions, unavailable content, and a failed action. The user should receive a clear next step rather than a dead end.
Ask a follow-up that depends on the previous answer. Correct an earlier detail and check whether the agent responds to the correction instead of repeating the old assumption. Review conversation logs after each test to compare the customer experience with the recorded exchange and identify missing context or training gaps.
AssistLoop can use website content, uploaded files, pasted text, and exact Q&A pairs as training sources. That gives you material to test, but training alone does not prove that the widget or conversation is accessible.
Test the path to a human
Give the customer a clear way to ask for a person when the answer is uncertain, sensitive, or outside the agent’s scope. Test the handoff control with a keyboard and screen reader. It should have a useful name, appear in the expected tab order, and tell the customer what will happen.
When the request starts, the customer should receive a clear status message while the handoff is pending. Check that the human receives useful conversation context and that the customer can keep reading, add information, and exit the widget without losing focus or context.
Test no available agent, delayed response, closed support hours, and a handoff that cannot be completed. Each path needs a clear next step. Do not leave the user staring at a spinner. AssistLoop human handoff is the product surface to evaluate here, not proof that the full site meets an accessibility standard.
How to do this with AssistLoop
Apply the review to the actual AssistLoop surfaces your team plans to launch. Embed the widget on a representative page, then run the launcher, focus, keyboard, screen-reader, zoom, visual-state, and mobile checks. Test the exact branding, avatar, greeting, theme, and suggested replies planned for production.
Next, test answers against the content you will provide to the agent. Use the product, billing, unknown-topic, follow-up, correction, and failed-action questions from the earlier sections. Review conversation logs after each run.
Then test human handoff from the widget, including the unavailable-agent and delayed-response paths. AssistLoop is not a product feature that certifies your entire site or support operation. Your team owns the accessibility review for the complete customer experience.
Record a buyer-ready pass or fail review
Use a table that makes ownership visible:
| Check | Owner | Test method | Expected result | Actual result | Evidence | Severity | Retest date |
|---|---|---|---|---|---|---|---|
| Open and close the widget | Web or QA owner | Keyboard and mobile test | User can open and close it without losing their place | Record the observed result | Screen recording | High, medium, or low | Date |
| Read a new response | Assistive technology tester | NVDA or VoiceOver | Response and status are announced in a useful order | Record the observed result | Audio or written test log | High, medium, or low | Date |
| Recover from an unknown question | Support owner | Conversation transcript | User gets a clear next step | Record the observed result | Transcript | High, medium, or low | Date |
| Request human help | Support and QA owners | Keyboard, screen reader, and failed handoff test | Handoff status and fallback are understandable | Record the observed result | Recording and transcript | High, medium, or low | Date |
Assign interface checks to web or QA, assistive technology checks to someone who uses the relevant tool, and conversation checks to a support owner who knows real customer questions. Do not treat an automated scan as a substitute for task testing.
Require a pass only when the task works from start to finish, including error recovery and exit. Keep separate defect categories for interface access, content clarity, AI behavior, mobile behavior, and human handoff. Repeat the review after widget changes, training-source changes, major site releases, and accessibility fixes.
AssistLoop widget customization gives teams controls for branding, avatar, name, greeting, light or dark theme, and suggested replies. Each visual or interaction change deserves a quick retest.
Start your own widget review
Do not approve an AI support widget because it answers a test question. Approve it only after a customer can open, operate, understand, recover, and reach a person using the access methods your audience needs.
If you are ready to run that review with your own support content, create an AI agent and test the widget before launch. AssistLoop gives you the widget, training, conversation, and human handoff surfaces to evaluate. Your team still owns the accessibility review for the full customer experience.
FAQ
Can an accessibility checklist replace a formal accessibility audit?
No. A checklist is a practical launch control for testing the widget and support journey. It does not replace a formal audit, legal review, or testing with people who use assistive technology.
When should a team repeat chatbot accessibility testing?
Repeat it after widget changes, training-source changes, major site releases, and fixes to accessibility defects. Retest the complete task path when a change affects focus, labels, visual states, responses, or handoff.
Should AI answer quality be part of an accessibility review?
Yes. Customers need answers they can understand and recover from when the agent cannot help. Review clear wording, follow-up context, error states, fallback behavior, and the route to human support alongside interface checks.
Who should own a chatbot accessibility review?
Web or QA owners can run interface checks, assistive technology users should run or guide screen-reader checks, and support owners should test real customer conversations. One person can coordinate the review, but the record should show who ran each test.
Written by