Is Your Chatbot Actually Usable by Everyone?

Chatbots have an accessibility problem

Customer service chatbots have become the primary — and often only — contact option for many digital products. The expectation is clear: if you need help, open the chat. If the chat doesn’t work for you, there’s often nothing else.

For users with disabilities, this situation is frequently untenable. Most commercial chatbots fail basic accessibility requirements. Screen reader users can’t hear messages as they arrive. Keyboard users get trapped inside the chat widget and can’t escape. Users with motor disabilities encounter touch targets too small to tap reliably. Users with cognitive disabilities face walls of text and no clear way to recover from a misunderstood query.

This matters both ethically and legally. The European Accessibility Act, in force since June 2025, covers the digital customer service channels of businesses in scope — which includes chatbot interfaces. The ADA in the United States has been applied to chatbots in web accessibility litigation. If a chatbot is a primary service channel, an inaccessible chatbot is a service exclusion.

The seven most common chatbot accessibility failures

1. Missing ARIA live regions

When a new message arrives in a chat window, a screen reader user needs to hear it. But screen readers only announce content they’ve been told is important and dynamic. Without an ARIA live region wrapping the chat message container, messages appear visually but are completely silent to screen reader users.

<!-- Without live region: new messages are not announced -->
<div class="chat-messages">
  <!-- Messages added here dynamically -->
</div>

<!-- With live region: new messages are announced as they arrive -->
<div
  class="chat-messages"
  role="log"
  aria-live="polite"
  aria-label="Chat conversation"
>
  <!-- Messages added here dynamically -->
</div>

role="log" is specifically defined in ARIA for chat conversations and message streams. aria-live="polite" announces new content after the user pauses — less disruptive than assertive for a conversational context.

2. Keyboard traps

A keyboard trap occurs when a user tabs into a component and can no longer tab out — they’re stuck. Chatbot widgets are among the most common places where keyboard traps appear.

The fix requires implementing proper focus management: Tab and Shift+Tab must navigate through interactive elements within the chat, and Escape must close the chat and return focus to the element that triggered it. WCAG 2.1.2 No Keyboard Trap (Level A) covers this requirement.

Testing this is simple: open your chatbot using only the keyboard, tab through all interactive elements inside it, and confirm you can exit using Escape or a clearly visible close button.

3. Insufficient color contrast

Chatbots are often rendered in brand colors, and brand colors are often not tested against WCAG contrast requirements. Common failures:

• Chat bubble text that doesn’t meet 4.5:1 contrast against the bubble background
• Input field placeholder text below contrast thresholds
• Timestamp text in very light grey

The contrast requirement applies to the chatbot interface just as it does to the rest of your site — there’s no exception for widgets.

4. Unlabeled input fields and buttons

The chat input field — “Type your message…” — must have a programmatically associated label, not just placeholder text. Placeholder text disappears as soon as the user starts typing and is not a reliable substitute for a label.

The send button, minimize button, close button, and any other interactive controls must have accessible names. An icon-only “send” button with no text and no aria-label is announced by screen readers as “button” with no description of its purpose.

<!-- Missing label: fails -->
<input type="text" placeholder="Type a message...">
<button><svg><!-- send icon --></svg></button>

<!-- With label and aria-label: passes -->
<label for="chat-input" class="sr-only">Type your message</label>
<input type="text" id="chat-input" placeholder="Type a message...">
<button aria-label="Send message">
  <svg aria-hidden="true"><!-- send icon --></svg>
</button>

5. Touch targets too small for motor-impaired users

WCAG 2.2 introduced 2.5.8 Target Size (Minimum) at Level AA, requiring interactive elements to have a minimum target size of 24×24 CSS pixels. Many chatbot UIs place close, minimize, and emoji buttons at 16–20 pixels — well below this threshold.

For users with motor disabilities, tremors, or reduced fine motor control, small targets are genuinely unusable. The chatbot’s action buttons are among the most frequently affected UI elements.

6. No timeout warning or session extension

Many chatbots end an inactive session after a set period. When this happens without warning, users who take longer to compose or read messages — including many users with cognitive or motor disabilities — may lose their conversation without any opportunity to extend the session.

WCAG 2.2.1 Timing Adjustable (Level A) requires that when a time limit is set, users can turn it off, extend it, or the limit is at least 20 hours. A chatbot that terminates sessions after 5 minutes of inactivity without warning is non-compliant.

7. Complex language and no error recovery

Chatbots are only useful if users can communicate with them effectively. For users with cognitive disabilities, learning disabilities, or lower literacy levels, a chatbot that uses jargon, provides long walls of text without structure, or fails silently when it doesn’t understand a query is functionally inaccessible.

Accessible chatbot content:

• Uses plain language (short sentences, common words)
• Breaks responses into scannable units rather than presenting paragraphs
• Provides clear error recovery: when the bot doesn’t understand, it says so explicitly and offers specific alternatives
• Supports users in reformulating queries rather than just saying “I didn’t get that”

New WCAG 2.2 criteria especially relevant to chatbots

WCAG 2.2 added several success criteria that apply with particular force to chat interfaces:

2.4.11 Focus Not Obscured (Minimum) — Level AA. When a chat widget is open, it must not completely hide the focused element behind it. Many chat widgets appear over page content and obscure the focused element when users tab through the underlying page.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA. The focused element should be fully visible.

2.5.7 Dragging Movements — Level AA. If your chat widget can be repositioned by dragging, a single-pointer alternative must exist.

2.5.8 Target Size (Minimum) — Level AA, as covered above.

How to test your chatbot

1. Keyboard only: open the chat without using a mouse. Tab through all elements. Verify you can type, send messages, and close the widget using only keyboard. Confirm you can exit with Escape.

2. Screen reader: open NVDA (Windows, free) or VoiceOver (Mac/iOS, built-in) and interact with the chat. Verify messages are announced as they arrive. Verify inputs and buttons are labeled correctly.

3. Zoom to 200%: verify the chat interface doesn’t overflow or obscure page content when text is enlarged.

4. Contrast checking: use a browser extension like axe DevTools or WAVE to check contrast in the chat UI.

5. Mobile: test touch target sizes and verify the chat works with iOS/Android accessibility features (VoiceOver, TalkBack).

If you’re integrating a third-party chatbot, assess the vendor’s accessibility before choosing. Ask for their VPAT (Voluntary Product Accessibility Template) to understand their claimed conformance level. Test the widget yourself — vendor claims don’t substitute for direct testing.

Building chatbot accessibility in from the start is significantly cheaper than retrofitting it. If you’re evaluating chatbot platforms, run each candidate through this checklist before committing.

For a comprehensive review of your chatbot and the rest of your digital customer service experience, talk to our team or start with a free scan of your public-facing pages.