A chat widget floats above every page, which means it is either an accessible front door for support or a floating obstacle on every single URL. For visitors using keyboards, screen readers, or magnification, the difference is whether they can ask for help at all — and support chat is disproportionately used by exactly these visitors.
Keyboard first
- The launcher must be focusable and activatable with Tab and Enter — a clickable div without a role is invisible to keyboard users.
- Focus must move into the panel when it opens and return to the launcher when it closes. A chat that opens without moving focus strands the keyboard user on the page behind it.
- Escape should close the panel, and Tab should cycle within it while open, not wander into the page underneath.
Screen readers: announce, don't just display
- Incoming messages belong in a live region (
aria-live="polite") so they are read aloud without stealing focus mid-typing.
- The launcher needs a real name ("Chat with us — online") that reflects state; "unread: 2" as text beats a visual-only red dot.
- Sound notifications need a visual twin, and visual ones need to reach assistive tech — never encode "an agent replied" in only one channel.
Contrast, size, motion
- Brand colors on the launcher still owe WCAG contrast (4.5:1 for text). A beautiful pale-teal "Leave a message" label fails real users daily.
- Touch targets: the launcher and the close button both need ~44px of hit area — the close button is the one everyone shrinks.
- Respect
prefers-reduced-motion: attention bounces and pulse animations should quiet down for visitors who ask the OS for less motion.
Many sites run overlay tools (UserWay, accessiBe and similar) that add their own floating button — usually the same corner chat widgets favor. Well-behaved tools reposition neighboring widgets to avoid overlap; a chat widget that stubbornly reasserts its own pixel position ends up fighting the overlay in a visible tug-of-war, and the visitor sees a button vibrating on their screen. The right behavior is to yield: if an accessibility tool has moved your widget a few pixels, stay moved. We learned this one in production — MyLiveChat's widget now detects overlay-tool repositioning and cooperates rather than competing.
Test it the honest way
Ten minutes, no tooling required: unplug your mouse and reach chat with Tab alone, send a message, close the panel. Then turn on your OS screen reader and do it again. Then set your OS to reduced motion and watch the launcher. Whatever failed is your accessibility backlog, in priority order — because a visitor who cannot open the chat cannot tell you they cannot open the chat.
Time pressure is an accessibility barrier
Live chat carries an implicit clock, and that clock excludes people. Someone using a switch device,
composing with assistive input, translating as they go, or thinking through a cognitive impairment may need
several minutes to write what another visitor types in ten seconds.
Design so that slow is safe. Avoid closing a conversation on a short inactivity timer, and where a
timeout exists, warn before it fires and make recovery painless. Never discard a message someone was in the
middle of writing.
Agents need to know this too. A visitor who has not replied for two minutes may be composing, not gone,
and the reflex of sending “are you still there?” twice reads as impatience to someone who is
working hard to answer. Give them a phrase that keeps the conversation open without applying pressure.
The conversation itself is part of the accessibility surface
Most accessibility guidance stops at the widget, but the message a visitor receives is what they came
for, and it can be as inaccessible as any control.
Write in plain language and keep sentences short. Do not rely on colour or formatting to carry meaning,
because a screen reader announces neither — if something is important, say that it is important in
words. Avoid sending a wall of text in one message; several short messages are easier to follow with a
screen reader and easier to hold in working memory.
Be careful with links and attachments. Link text should describe its destination rather than saying
“click here”, and if you send a document, say what it is and what it contains, because a
visitor may not be able to skim it as quickly as you assume. Offering a transcript at the end helps anyone
who needs to revisit the conversation at their own pace.
What to measure
Run a keyboard-only pass and a screen-reader pass on a schedule rather than once at launch. Widget
updates, site CSS changes and new custom styling can each break what previously worked, and nothing will
alert you.
Watch abandonment among visitors who opened the widget and never sent a message. A persistently high
rate can indicate a control that is hard to operate rather than a change of mind, and it is worth
investigating with an actual assistive technology rather than an automated checker.
Treat any accessibility complaint as a defect with a named owner, not as feedback. These reports are
rare relative to the number of people affected, because most people who cannot use something simply leave,
so each one represents considerably more visitors than it appears to.