Launcher and controls
- Use native buttons where possible.
- Give icon-only controls accessible names.
- Keep labels stable and specific.
- Provide visible hover, focus, disabled, and open states.
Accessible chatbot review
Website Chatbot Accessibility Checklist
A practical, source-cited checklist for reviewing the launcher, keyboard path, focus, dialog behavior, dynamic messages, lead forms, errors, zoom, mobile use, and fallback contact options.
Check the complete conversation path.
A website chatbot is more than its message text. The launcher, dialog, controls, focus behavior, status updates, form fields, errors, and fallback contact route all affect whether a visitor can use it. WCAG provides testable accessibility requirements, while the WAI-ARIA Authoring Practices explain interaction patterns for widgets.[1][2]
Scope note: this checklist supports evaluation and remediation planning. It does not certify this site, its current widget, or any other implementation against WCAG or legal accessibility requirements.
Website chatbot accessibility checklist
Keyboard operation
- Reach every interactive control with the keyboard.
- Use a logical focus order.
- Do not create a keyboard trap.
- Support expected keys without overriding browser shortcuts.
Dialog behavior
- Move focus deliberately when chat opens.
- Keep the close control reachable.
- Return focus to the launcher when chat closes.
- Test Escape behavior and background interaction.
Messages and status
- Expose new replies without stealing focus.
- Announce sending, errors, and completion at useful moments.
- Avoid repeatedly reading the entire transcript.
- Keep visual and programmatic message order aligned.
Forms and errors
- Associate every field with a clear label.
- Explain required data and input formats.
- Identify errors in text, not color alone.
- Let visitors review and correct captured details.
Visual and mobile use
- Check text and control contrast.
- Keep focus indicators visible.
- Support zoom and narrow screens without lost controls.
- Respect reduced-motion preferences where animation is used.
Test keyboard behavior from closed to closed.
WAI-ARIA guidance distinguishes focus—the active keyboard location—from selection, and warns against positive tabindex values because they are difficult to maintain.[2] Begin with the chatbot closed. Tab to the launcher, open it, move through every control, enter and edit a message, submit it, reach any error or retry control, and close the panel. Confirm that focus remains visible and returns somewhere predictable.
If the chat is implemented as a modal dialog, compare its behavior with the APG modal-dialog pattern: focus moves inside on open, keyboard focus stays within the modal, Escape closes it, and focus generally returns to the invoking control.[4] Apply that pattern only when the implementation really is modal; a nonmodal panel needs behavior appropriate to its actual interaction model.
Make updates understandable without moving focus.
Chat replies, typing states, send failures, and lead confirmations are dynamic updates. ARIA Technique ARIA23 describes using role="log" for sequential information such as chat logs and notes that new content is announced while focus remains on the visitor's current task.[3]
- Test one short reply, several rapid replies, a long reply, and an error.
- Confirm announcements provide enough context without becoming repetitive.
- Do not add ARIA that duplicates native semantics or causes the whole transcript to be reread.
- Check the experience with more than one browser and screen-reader combination relevant to the audience.
Treat lead capture as a real form.
W3C's forms tutorial recommends explicit labels, instructions, validation, and understandable feedback.[5] A chatbot that asks for a name, email, phone number, location, or service need still creates a form-like task even when fields appear one question at a time.
Tell visitors why information is needed, distinguish required from optional fields, preserve their entries after an error, and provide a way to correct information before submission. Do not rely on placeholder text as the only label.
Inspect the rendered widget on its host page.
Host-page CSS, overlays, sticky headers, zoom, viewport height, and mobile keyboards can change the widget after it leaves a dashboard preview. Test at narrow and wide widths, 200% zoom, text enlargement, light and dark themes, touch, keyboard, and reduced motion. Check that the launcher does not obscure essential content and that the open panel does not place its close or send controls offscreen.
Accessibility is not established by automated scanning alone. Combine machine checks with keyboard testing, assistive-technology testing, visual inspection, and task-based review by people with relevant access needs.
Record pass, fail, and known limits.
- Pass: state the exact browser, device, assistive technology, task, and result.
- Fail: record reproduction steps, expected behavior, actual behavior, severity, and ownership.
- Known limit: explain the unsupported scenario and provide a usable alternative contact route.
- Retest: rerun the original failure after changes and check nearby behavior for regressions.
For measurement after launch, read How to Measure AI Chatbot Performance. For broader planning, return to the industries hub.
Sources and further reading
- W3C WAI: WCAG standards and guidelines — overview of the international accessibility standard and supporting resources.
- WAI-ARIA APG: Developing a Keyboard Interface — focus, keyboard conventions, and widget operability guidance.
- WCAG Technique ARIA23: Using role=log — a technique for sequentially added information such as chat logs.
- WAI-ARIA APG: Dialog (Modal) Pattern — keyboard interaction, focus placement, and labeling for modal dialogs.
- W3C WAI Forms Tutorial — labels, instructions, validation, notifications, and form structure.
Review the launcher, conversation, capture, and fallback together.
Bring the host page, expected visitor tasks, target devices, and known constraints to a scoped accessibility review.