Tab, Trap, Repeat: The Live-Chat Accessibility MOT Your UK Sales Team Can Run This Week
Most UK SMEs do not set out to build an inaccessible live-chat widget. They buy one, paste the script into the template and move on. The trouble is that the features which make chat convenient for most shoppers — a floating bubble, a slide-out panel, a quick CAPTCHA — can quietly lock out the people who need help with a quote, a delivery or a checkout glitch.
That is not just an Equality Act 2010 box-ticking exercise. It is a sales leak. If someone cannot reach your team, they rarely fill in a contact form and wait patiently. They go to a competitor whose chat works with a keyboard, a screen reader or larger text.
The good news: you do not need a full site rebuild to catch the worst problems. You need a focused audit, a short fix list and someone with half an hour a week. This is not legal advice; it is a practical sales and service review for small UK teams.
Put the mouse away: the keyboard test
Start by opening your site and ignoring the mouse entirely. Press Tab repeatedly. Can you reach the chat launcher? When you do, does it open with Enter or Space? Once the panel is open, can you move through the message history, type in the input box and send without getting stuck?
The common failures are boringly predictable. Focus disappears behind the widget. The close button cannot be reached. The send button only responds to a mouse click. Worst of all, the chat panel becomes a keyboard trap: you can tab into it but not out again. That single issue can make the rest of your site unusable for a keyboard-only visitor.
Fix the trap first. Everything else can wait.
Does your chat announce itself to a screen reader?
A screen reader user needs to know three things: that chat exists, that a new message has arrived, and where to type a reply. Many widgets fail on all three.
Ask someone to test with NVDA, VoiceOver or TalkBack if you can. If not, at least inspect the basics. The launcher needs a sensible label, not just an icon. The message history should be announced as a live region when new replies arrive, but it should not hijack focus every time an agent types. The input field needs a proper label. The send button needs a name that makes sense out of context.
A chat panel that is visually obvious but silent to assistive tech is not a shortcut. It is a dead end with a nice gradient.
Contrast, text size and the boring bits that cost sales
Accessibility audits often get stuck on the technical stuff, but some of the highest-impact fixes are visual. Pale grey placeholder text on a white background is a classic. So is a low-contrast send button, or a chat bubble that looks lovely in Figma and disappears on a bright laptop screen.
WCAG 2.2 level AA is a useful benchmark even if you are not legally required to meet it. For most chat interfaces, that means aiming for a 4.5:1 contrast ratio for normal text and making sure the widget respects browser text-size settings. If your chat panel breaks when someone zooms to 200%, that is a problem.
It also helps to check reduced motion settings. A chat bubble that bounces, pulses and slides in is charming once. It is a distraction for someone who has asked their operating system to calm animations down.
Timed chats, idle timeouts and the disappearing transcript
Many chat platforms disconnect an idle visitor after a set period. That is fine for queue management, but it is hostile if the visitor is using a screen reader, typing slowly or switching between devices.
The fix is not complicated. Warn people before the session ends. Offer a clear way to extend it. And make sure the transcript is sent by email or made available in an accessible format afterwards. A transcript that only exists inside the closed widget is not much use to someone who needs to refer back to it later.
If your agents routinely send PDFs, check that those PDFs are readable by assistive tech. A scanned image of a chat transcript is not an accessible record. Plain HTML or a properly tagged document is better.
CAPTCHAs and the prove-you-are-human problem
CAPTCHAs are a familiar accessibility weak spot. Image puzzles, distorted audio and drag-and-drop tasks can all exclude people. If you use one before chat, ask whether it is really necessary. Many SME chat setups do not need a CAPTCHA at all, especially if you already have rate limiting and spam filtering.
If you do need one, provide an alternative route. A phone number, an email address or a simple accessible challenge is better than a puzzle with no way through. The goal is not to make life easy for bots; it is to avoid making life impossible for customers.
The prioritised fix list for a small team
You can spend months on accessibility. You do not need to. Work through this list in order, based on sales impact and effort.
- Kill keyboard traps. Make sure a keyboard user can open, use and close the chat without getting stuck.
- Label the launcher, input and send button. Clear names help screen reader users and improve voice control.
- Fix the worst contrast issues. Start with placeholder text, buttons and message bubbles.
- Add a timeout warning and an easy extension. Do not let a slow typist lose the conversation.
- Offer a non-chat contact route. A visible phone number or email address is a useful backstop.
- Review your CAPTCHA. Remove it if you can; supplement it if you cannot.
- Make transcripts accessible. Send them by email and avoid image-only PDFs.
- Re-test quarterly. Widget updates and theme changes can break things quietly.
What to ask your vendor
If you are buying or renewing a live-chat platform, ask direct questions. Does the widget meet WCAG 2.2 AA? Can we change labels and contrast without custom development? Does it respect reduced motion? Can transcripts be emailed as accessible HTML? Can we turn off the CAPTCHA or provide an alternative?
A vendor that cannot answer those questions is not necessarily a bad vendor, but you should know what you are taking on. For a small UK sales team, accessibility is not a specialist project. It is part of making the chat channel actually work for the customers who need it most.
