The chat bubble in the bottom corner is usually the last thing added to a site and the first thing a visitor sees on every page. It came from a vendor, it was pasted in with one script, and nobody tested it beyond “does it open?”. Then an audit flags it on all forty pages at once, or a customer using a screen reader says the site kept talking about “button” with no name.
Chat widget accessibility matters more than its size suggests, because a single widget repeats its barriers everywhere. Here is what to check in the launcher, the window and the messages, plus floating WhatsApp and call buttons, and how to judge a vendor before you sign up.
Chat widget accessibility starts with the launcher
The launcher is the round icon that opens the chat. It is a button, so it needs three things:
- A name. “Open chat” or “Chat with us”, announced by a screen reader. A bare speech-bubble icon gives a screen reader nothing to say beyond its role, if that.
- Keyboard access. It should be reachable with Tab and open with Enter or Space. Some launchers are drawn as a div that only listens for clicks.
- A visible focus state. When someone tabs to it, they should see it. Our post on visible focus indicators covers what good focus looks like.
Contrast counts too. A pale bubble on a white page can fall below the 3:1 non-text contrast that WCAG asks for on controls people need to find.
Where does the launcher sit in the tab order? Many widgets inject themselves at the very end of the page, which is fine. Some insert themselves at the top, so a keyboard user hits the chat before the main menu on every page load.
When the bubble covers the page
Floating launchers, cookie notices, “back to top” arrows and WhatsApp buttons all compete for the same corner. On a phone, they can cover the last line of text, a form’s submit button or the cart total.
One of the criteria added in WCAG 2.2 targets exactly this. Under 2.4.11, a control that has just received keyboard focus cannot be completely covered by something the site itself layered over it. A keyboard user tabbing to the last footer link while the chat bubble sits squarely on top of it is the case it was written for.
Ways to deal with it:
- Leave space at the bottom of the page so content can scroll clear of the bubble.
- Use the vendor’s position and offset settings to move it away from key buttons.
- Use a smaller launcher on mobile, or a text tab at the edge, if the widget offers one.
- Do not stack several floating buttons on top of each other. Pick one.
Zoom matters here as well. At high zoom levels, a fixed bubble takes a much bigger share of the screen. Try your pages at 200 percent and see what it hides.
The chat window
Once opened, the chat window behaves like a small dialog. The questions are the same as for any panel that appears over a page; our post on accessible popups and modals goes deeper into the general pattern. For chat specifically, check:
- Focus moves in. After opening, focus should go to the message field or the window’s heading, not stay on the launcher behind it.
- It can be closed. A named close or minimize button, and Escape should close it. Focus should then return to the launcher.
- No trap. A keyboard user must be able to leave. Some widgets catch Tab inside the window with no way out; others let focus wander into the page behind while the window stays open. Either one is a problem.
- The message field has a label. “Type your message” in a placeholder only is not enough.
- Pre-chat forms work. Many widgets ask for name and email first. Those fields need labels and clear errors like any other form.
- It reflows. On a narrow screen or zoomed in, the window should fit without hiding its own send button.
Also watch for auto-open. A chat that pops open on its own after a few seconds, grabs focus and starts a conversation interrupts screen reader users mid-sentence. If the widget has an auto-open or proactive greeting setting, consider turning it off, or at least making sure it does not move focus.
Announcing new messages
Live chat is a conversation, and a conversation is useless if one side cannot hear the replies. When an agent or a bot answers, the new message should be announced by screen readers without the user moving focus. In code terms the message list needs to be a live region, the mechanism behind the Status Messages criterion (4.1.3).
Good accessible live chat also:
- Labels who said what, so “Agent: Your order shipped” is read, not just the text.
- Avoids announcing every typing indicator, which becomes noise quickly.
- Gives quick-reply buttons real names, not just emoji.
- Does not expire the session silently while someone is still typing a reply.
To test it, open the chat with NVDA or VoiceOver running, send a message, and keep your hands off the keyboard. If the reply is not read aloud, it is not being announced.
WhatsApp, call and message buttons
Some businesses add a floating WhatsApp, text or call button instead of a full chat. These are simpler, but they share the same issues: they need a text name (“Message us on WhatsApp”), enough size to tap, contrast, and a position that does not cover content or focus. If the button opens an app or a new tab, say so in its name or nearby text.
Do not make it the only contact route. Some people cannot use phone calls, and some do not use WhatsApp at all. A plain email address and phone number on the contact page cover them.
How to judge a chat vendor
Most chat widgets come from third parties, which puts much of chat widget accessibility in the vendor’s hands. You cannot fix their code yourself, but you can choose well and push for fixes. Before signing up, or when your contract comes up for renewal:
- Ask whether the widget has been tested against WCAG 2.2 AA and whether they can share an accessibility conformance report or similar document.
- Try their own demo with a keyboard and a screen reader. If the demo fails, yours will too.
- Check which settings exist for position, auto-open, colors and greeting behavior.
- Ask how they handle reported accessibility bugs and whether fixes reach all customers.
On WordPress, a chat plugin or embedded script also affects page speed. That side is covered in our posts on choosing a live chat plugin for WordPress and chat widgets that slow a site down.
Vendors update their widgets on their own schedule, so a chat that passed your last check can fail the next one without any change on your side. Recheck it whenever the vendor announces changes, and as part of any ongoing accessibility maintenance. Audits and fixes in general are described in our accessibility services for US businesses, and the online store accessibility guide puts chat in the context of a full shopping trip.
Frequently asked questions
Can a chat widget make my whole site fail an accessibility check?
It can cause problems on every page, because it loads everywhere. A launcher that covers content or focus, an unnamed button, or a chat window that traps the keyboard will show up wherever the widget appears. That is why it is worth testing the widget on its own and raising issues with the vendor quickly.
Is a WhatsApp button accessible?
It can be. The floating button needs a clear text name such as Chat with us on WhatsApp, enough contrast and size, and a position that does not cover page content or keyboard focus. Also make sure people who do not use WhatsApp have another way to reach you, such as an email address or phone number shown as text.
How do I know if new chat messages are announced to screen readers?
Open the chat with a screen reader running, send a message, and wait for the reply without moving. If the reply is read out automatically, the widget is announcing messages. If you have to go looking for it, the message area is not set up as a live region and the vendor should fix it.
Should I remove the chat widget if it is not accessible?
If it creates a keyboard trap or hides content and the vendor cannot fix it, removing it or switching vendors is reasonable. Before that, check whether settings such as position, auto-open and colors solve the worst problems. Always keep a plain contact option on the site so nobody depends on the chat alone.
On stores, the chat bubble often sits right over the cart total or the checkout button on phones. If that sounds like your WooCommerce site, our WooCommerce accessibility page explains how we check the whole store, chat and all, and fix what we find.
