AI Chatbot Accessibility: WCAG 2.2 Compliance Guide
An accessible AI chatbot is a legal requirement, not a nice-to-have. Here's the WCAG 2.2 AA conformance recipe, ARIA patterns, keyboard handling, screen-reader behavior, and a 30-point audit you can run today.
Why this matters in 2026
ADA lawsuits targeting chat widgets crossed 4,000 in 2025. The EU's European Accessibility Act took effect June 28, 2025, non-compliant chatbots on e-commerce and digital service sites carry six- and seven-figure penalties. Build it accessible from day one.
The 30-Point Audit
Structure
- • role="log" on conversation transcript
- • aria-live="polite" for bot responses
- • aria-label on widget toggle button
- • Heading hierarchy (h1, h2) inside expanded chat
- • Landmark roles (region, complementary)
Keyboard
- • Tab to focus widget toggle
- • Enter/Space to open
- • Esc to close
- • Tab through messages, input, send button
- • Focus trap inside open widget
- • Visible focus indicator (min 2px, 3:1 contrast)
Color & Contrast
- • Text contrast 4.5:1 minimum (AA)
- • UI element contrast 3:1
- • Don't rely on color alone (use icons + text)
- • Respect prefers-reduced-motion
- • Dark mode contrast tested
Screen Reader
- • Bot name announced on first message
- • Typing indicator audible (or skippable)
- • Quick-reply buttons read as buttons
- • Send button has accessible name
- • Errors announced via aria-live="assertive"
Content
- • Plain language (Grade 8 reading level or below)
- • Avoid emoji-only meaning
- • Spell out abbreviations on first use
- • Alt text on bot-sent images
- • Captions on bot-sent video
Mobile
- • Touch targets ≥44×44px
- • No double-tap-to-zoom blocked
- • Respect dynamic font size
- • Pinch-zoom not disabled
- • Orientation lock not forced
Minimal Accessible Chat Markup
<button
aria-label="Open EzyConn chat"
aria-expanded="false"
aria-controls="chat-panel"
>Chat</button>
<section
id="chat-panel"
role="region"
aria-label="EzyConn chat window"
hidden
>
<div role="log" aria-live="polite" aria-atomic="false">
<!-- Messages append here -->
</div>
<form>
<label for="chat-input">Type a message</label>
<input id="chat-input" type="text" autocomplete="off" />
<button type="submit">Send</button>
</form>
</section>What WCAG 2.2 changed for chat widgets
Most teams built their chat UI against WCAG 2.1 and assume they are done. Version 2.2 (a W3C Recommendation since October 2023) added nine new success criteria, and three of them hit chat widgets directly. If your last audit predates 2.2, these are the gaps.
- • 2.4.11 Focus Not Obscured (AA). When the chat panel slides open, it must not cover the control the user just focused. Sticky launchers and slide-up sheets are the usual culprits. Confirm the focused element stays at least partially visible.
- • 2.5.8 Target Size (Minimum) (AA). Interactive targets need at least 24 by 24 CSS pixels, with spacing exceptions. Tiny close icons and cramped quick-reply chips are the common misses. We aim for 44px in practice because it is more comfortable on a phone.
- • 3.3.8 Accessible Authentication (AA). If your bot ever gates a flow behind a login or a code, do not force the user to memorize or transcribe something. Allow paste, password managers, and copy from another app.
One more that trips people up even though it predates 2.2: if your chat session can time out, SC 2.2.1 requires you to warn the user and let them extend it. A bot that silently drops a conversation after a few idle minutes fails, and it frustrates everyone, not only assistive-tech users. Keep the timeout generous and announce it.
How to actually test it
A green Lighthouse score is not a passing grade. Automated tools catch roughly a third of WCAG issues, mostly the markup-level ones. The failures that get sites sued are the ones only a human notices. Here is the testing pass we run before we call a chat widget conformant.
- Automated first. Run axe DevTools or Lighthouse against the open widget, not just the closed toggle. Many bots pass when collapsed and fail once the panel expands.
- Keyboard only. Unplug the mouse. Tab to the launcher, open with Enter or Space, Tab through messages, type a question, send with Enter, and close with Esc. If focus escapes to the page behind the open panel, you have a keyboard-trap failure in reverse.
- Screen reader. Turn on VoiceOver (Mac / iOS), NVDA (free on Windows), or JAWS. Send a message and confirm the bot's reply is spoken without you touching anything. Silence here is the number-one failure.
- Zoom to 200%. Per SC 1.4.10, content must reflow without horizontal scrolling. Check the input box does not get clipped.
- Reduced motion. Enable the OS setting and confirm the typing indicator and open animation calm down or stop.
Map it to WCAG 2.2 success criteria
When a complaint or audit lands, "we followed best practices" is weaker than pointing to specific criteria. These are the ones a chat widget lives and dies on.
| Success criterion | What it means for chat | Pass condition |
|---|---|---|
| 4.1.3 Status Messages | New bot replies must reach assistive tech | role="log" with aria-live="polite" |
| 2.1.2 No Keyboard Trap | User can leave the open widget with the keyboard | Esc closes, focus returns to launcher |
| 2.4.7 Focus Visible | Every control shows where focus is | Visible ring, min 2px, 3:1 contrast |
| 2.4.11 Focus Not Obscured | The open panel must not hide the focused element | Focused control stays in view (WCAG 2.2) |
| 1.4.3 Contrast (Minimum) | Message text is readable | 4.5:1 text, tested in light and dark |
| 2.5.8 Target Size (Minimum) | Tap targets big enough on mobile | 24x24 CSS px minimum (WCAG 2.2) |
| 3.3.2 Labels or Instructions | The input has a real label | Visible label or aria-label on the field |
A remediation story
A mid-size retailer got a demand letter over their support chat. The specific complaint: a blind customer using NVDA could open the widget but never heard the bot's replies, so they could not complete a return. Two failures were doing the damage, a message log with no live region (SC 4.1.3) and quick-reply chips built from clickable divs with no button role or accessible name.
The fix took a developer about nine days: wrap the transcript in role="log" with aria-live="polite", rebuild the chips as real buttons, add a focus trap with Esc-to-close, and raise the send button contrast from 2.9:1 to 4.8:1. None of it was hard. It was expensive only because it happened under a legal deadline instead of during the build. If you are choosing a widget now, a no-code AI chatbot that is conformant by default saves you this entire scenario, and the same accessible widget can run as your website AI chatbot everywhere it appears.
Common Failures to Avoid
- • Div soup. Buttons made of divs without role="button".
- • Silent bot replies. No aria-live = screen readers miss the message.
- • Forced color. Hard-coded background ignoring user's OS theme.
- • No focus trap. Tab key escapes back to page when modal is open.
- • Animation without controls. Typing indicators that ignore prefers-reduced-motion.
Frequently Asked Questions
Legally required?
Yes. ADA Title III in the US regularly cites chat widgets, and the European Accessibility Act has applied to e-commerce and digital services in the EU since June 2025.
#1 failure?
Missing aria-live announcement on bot replies. Screen-reader users never hear that the bot responded.
How do I actually test it?
Automated pass with axe or Lighthouse, then the two manual tests: complete a conversation with the keyboard only, and run a screen reader to confirm every reply is announced. Automation catches about a third of issues.
Do overlays make it compliant?
No. Instant-compliance overlays do not fix the underlying markup and have themselves been named in lawsuits. Build it right instead.
How long is remediation?
Budget 1 to 2 engineering weeks to fix an existing widget. Building it accessible from day one costs almost nothing extra.
Is EzyConn accessible out of the box?
Yes, WCAG 2.2 AA conformant with ARIA, keyboard, screen-reader, and reduced-motion support, so there is nothing to remediate after launch.
Accessible by default
EzyConn ships WCAG 2.2 AA-conformant out of the box, ARIA, keyboard, screen-reader, reduced motion. Audit-ready.
Start FreeLast updated . View more guides.