A chat widget is a small application sitting on top of your website, and like any interface it can work well for everyone or shut some visitors out. People who use keyboards instead of mice, screen readers, magnification, voice control or high-contrast settings should be able to open the chat, read replies, type messages, book and reach a person. Accessibility is a matter of fairness and, in many places, of law. It is also good business: an accessible chat is usually a better chat for everybody. This guide turns the Web Content Accessibility Guidelines (WCAG) into a practical checklist for chat widgets, with tests you can run yourself in an hour.
This article is general information, not legal advice, and it does not claim that any product meets WCAG. Check the official guidelines at the W3C WCAG overview and test your own site. Legal requirements differ by country and sector.
Why chat widgets are often inaccessible
- They are built as floating overlays with custom controls that lack proper labels.
- Keyboard focus can get lost or trapped inside the widget.
- New messages appear without being announced to screen readers.
- Colours are chosen for branding, not contrast.
- Small buttons are hard to tap or click.
- Animations and auto-opening chats surprise and distract.
These are fixable, and most are visible in a short test.
The four principles, applied to chat
| WCAG principle | Meaning | In a chat widget |
|---|---|---|
| Perceivable | Information can be perceived by everyone | Text alternatives, sufficient contrast, messages announced, resizable text |
| Operable | Everyone can use the controls | Keyboard access, visible focus, no traps, enough time, large targets |
| Understandable | Content and operation are clear | Plain language, predictable behaviour, helpful errors |
| Robust | Works with assistive technologies | Proper roles, names and states in the code |
Checklist: opening and closing the chat
- The chat button can be reached and activated with the keyboard (Tab and Enter or Space).
- The button has an accessible name such as 'Open chat', not just an icon.
- Its state is exposed: a screen reader knows whether the chat is open or closed.
- When the chat opens, focus moves into it, ideally to the message input or the chat heading.
- The Escape key closes the chat, and focus returns to the chat button.
- The chat does not open by itself in a way that steals focus or interrupts reading.
Checklist: reading messages
- New messages are announced to screen readers, for example through a live region, without repeating the whole conversation.
- Each message identifies who wrote it, such as 'Assistant' and 'You', in text and not colour alone.
- Text can be enlarged to 200 percent without loss of content.
- Line length and spacing stay readable.
- Links are distinguishable and have clear names.
- The transcript is scrollable by keyboard.
The status messages criterion in WCAG 2.2 (4.1.3) is what makes 'assistant is typing' and new replies audible to screen reader users without moving focus.
Checklist: writing and sending
- The message input has a visible or programmatic label.
- Send works with the Enter key and has a labelled button.
- Quick-reply buttons are real buttons with clear names.
- Errors, such as a failed send, are described in text and announced.
- Required fields, such as booking details, are identified and validated with helpful messages.
- Nothing depends on drag, swipe or hover alone.
Checklist: colour, contrast and size
| Requirement | Guideline |
|---|---|
| Text contrast | At least 4.5 to 1 for normal text; 3 to 1 for large text |
| Interface components and icons | At least 3 to 1 against the background |
| Focus indicator | Clearly visible when a control is focused |
| Touch and click targets | Large enough; WCAG 2.2 sets a minimum of 24 by 24 pixels with spacing, and larger is kinder |
| Colour not the only cue | Do not rely on colour alone to distinguish sender or status |
| Resize | Layout works at 200 percent zoom and on narrow screens |
Brand colours often fail contrast. Test your chat's colours with a contrast checker and adjust the widget theme, not just your website's.
Checklist: motion, timing and interruptions
- Respect the user's reduced-motion setting: no animated typing effects or bouncing bubbles that cannot be turned off.
- Avoid auto-playing sound.
- Do not close the chat or time out without warning while someone is typing.
- Do not pop up repeatedly after being dismissed.
- Allow enough time to read and respond.
Checklist: booking and forms inside chat
- Date and time pickers work with a keyboard and a screen reader; offer a text alternative such as a list of times.
- Slots are described in words, for example 'Thursday 12 June, 10:30 a.m.', not only by position.
- Confirmation is stated clearly and announced.
- Any change or cancellation link is a real link with a meaningful name.
A visual calendar grid that cannot be used with a keyboard is a common failure. A simple list of available times is often more accessible than a fancy picker.
Content and tone
- Use plain language and short sentences.
- Avoid jargon and unexplained abbreviations.
- Do not use emojis as the only carrier of meaning, and avoid long strings of them, which screen readers read out.
- Offer a route to a person, and describe it clearly, including phone and email options for people who cannot use chat.
- State that the assistant is an AI in text.
How to test in an hour
- Keyboard only. Put your mouse aside. Tab to the chat button, open it, ask a question, book an appointment, close it. Can you do everything and always see where focus is?
- Zoom. Set the browser to 200 percent and check the chat still works.
- Screen reader. Use the one on your computer (VoiceOver on Mac, Narrator or NVDA on Windows) and listen to the chat opening, a new reply and a booking confirmation.
- Contrast. Check text and button colours with a contrast tool.
- Reduced motion. Turn on the setting in your operating system and see if animations stop.
- Mobile. Try touch targets on a phone.
- Automated scan. Run a free accessibility checker on a page with the chat open, remembering that tools catch only some issues.
| Test result | Action |
|---|---|
| Cannot reach the chat by keyboard | Report to the vendor; provide another route to contact you |
| Screen reader silent on new messages | Report to the vendor with details |
| Low contrast | Change theme colours |
| Auto-opening chat interrupts | Turn off auto-open |
What to ask your chatbot vendor
- Do you test the widget with keyboards and screen readers, and can you share results?
- Which WCAG version and level do you aim for?
- Is there an accessibility statement?
- How do I report an accessibility problem, and how fast are they fixed?
- Can I change colours, size and auto-open behaviour?
Be wary of claims of blanket 'compliance'; look for evidence and test yourself. Crescelo lets you customise the widget's colours and behaviour, so you can adjust contrast and turn off features; see the website widget feature. We do not claim that any widget meets a standard without testing on your site.
Offer alternatives
Whatever you do, a chat should never be the only way to reach you. Publish a phone number, an email or form, and mention them in the chat. Some visitors cannot or will not use chat, and being reachable another way is both kind and, in some places, required.
A short accessibility statement for your chat
Add a line near the chat or on your accessibility page: 'Our chat assistant is an AI. If you have trouble using it, contact us by phone or email and we will help you in another way. Tell us about any problem so we can fix it.' Then honour it: monitor the inbox, respond quickly and record and fix problems. A visible route for feedback is as important as any technical feature, and it shows visitors that you take access seriously.
Ongoing maintenance
Accessibility is not a one-time fix. Every time you change the widget's colours, greeting or position, or your vendor updates the widget, re-run the quick tests: keyboard only, 200 percent zoom, a screen reader pass and a contrast check. Put it on the same schedule as your other content reviews.
Related reading
- How to add an AI chatbot to your website includes accessibility in the launch checklist.
- Performance of embedded chat widgets covers page speed, which also matters for accessibility.
- Customizing widget branding with CSS shows how to adjust colours safely.
- AI transparency and disclosure covers telling visitors they are talking to an AI.
Frequently asked questions
Does WCAG apply to chatbots?
Yes. WCAG applies to web content, including widgets such as chat. Legal obligations depend on your country and sector.
Is my chatbot ADA compliant?
That depends on the widget, your site and the law that applies to you. Test with keyboard and screen readers, review the vendor's evidence and take advice. No widget can guarantee legal compliance on its own.
What is the most common chatbot accessibility problem?
Poor keyboard support and messages that are not announced to screen readers, followed by low colour contrast.
How do I make new messages accessible?
Use a live region so screen readers announce new messages without moving focus, and label who wrote each message.
Should the chat open automatically?
Avoid it. Auto-opening can steal focus and interrupt reading; let visitors choose.
Can I test accessibility myself?
Yes. Use keyboard only, zoom to 200 percent, a screen reader, a contrast checker and an automated scan.
See how to add a chatbot to your website with a checklist that includes accessibility, try an assistant in the playground and start a free trial.
SVARA ALLA BESÖKARE. BOKA DEM SOM ÄR REDO.
Lägg in Crescelo på din webbplats på 15 minuter
Träna din assistent på dina prislistor, dokument och tjänstevillkor. Aktivera välgrundade svar dygnet runt och bokning av tider direkt i chatten utan krockar.