The widget is part of your site's accessibility
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.
Coexist with accessibility overlay tools
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.