WCAG 2.2 Chat Widget Accessibility Checklist

Accessibility is not optional for an embedded AI assistant. A chat widget touches navigation, forms, feedback, and analytics, so a small mistake can create an ADA risk or a frustrating experience. Here is a practical checklist tuned for WCAG 2.2 AA and the realities of shipping quickly.

Design and theming

• Avoid color-only signaling. Use icons or text for error, success, and info states.
• Keep minimum contrast: 4.5:1 for body text, 3:1 for icons and chat bubbles.
• Respect user font size preferences. Use relative units and avoid hard coded pixel clamps.
• Make tap targets at least 44x44 px for open, close, send, and thumbs buttons.

Keyboard support

• The launcher must be focusable and reachable by Tab.
• When the widget opens, focus should move to the message input. On close, return focus to the launcher.
• All actions (send, attach, thumbs down) must be operable via keyboard without hidden shortcuts.
• Trap focus only when the widget is open, not when minimized.

Screen reader semantics

• Add clear labels: “Open chat”, “Close chat”, “Message input”, “Send message”, “Feedback”.
• Mark the transcript container as role="log" or role="region" with aria-live="polite" so new answers announce without stealing focus.
• Include concise timestamps to avoid verbosity.
• Provide status text for connection errors or throttling instead of silent failures.

Motion and visual comfort

• Detect prefers-reduced-motion and disable typing dots, high-frequency hover animations, and sliding transitions.
• Keep loading indicators simple; avoid looping animations that read as flicker.
• Prevent scroll jumping when new messages arrive. Append smoothly without auto-scrolling away from the focus point.

Forms and input

• The input should announce validation errors (length, blocked terms) with aria-describedby.
• Preserve the drafted message if a validation error occurs.
• Provide a logical tab order: input, send button, feedback controls, close.

Language handling

• If you auto-detect browser language, persist the choice so users are not bounced between locales.
• Announce language switches only once per session to avoid noisy screen reader output.
• Localize labels, hints, and error messages, not just the AI replies.

Analytics and privacy

• Respect consent banners before loading analytics inside the widget.
• Do not block keyboard or screen reader access if consent is withheld.
• If you record transcripts for quality, state it clearly near the input and provide a link to your policy.

Testing workflow

• Run an automated scan (axe, Lighthouse) but always pair it with manual keyboard and screen reader sweeps.
• Test in a reduced-motion profile and with high-contrast mode enabled.
• Verify embed CSP still allows the accessibility scripts and styles you need (fonts, analytics endpoints).

How CrawlBot helps

• The widget ships with WCAG-friendly defaults: labeled controls, stored language preference, and polite live regions.
• Embed CSP is strict by default, which helps prevent third-party scripts from hijacking focus or inserting inaccessible UI.
• Analytics capture per-embed metrics without additional tracking snippets, reducing the risk of breaking accessibility.

Ship the chatbot only after you can tab through it comfortably with your eyes closed. An accessible assistant is faster for everyone and keeps legal risk low.