Here's a two-minute test you can run on your own site right now, no tools required. Load your homepage with your chat widget docked open in the bottom corner like it always is. Click somewhere near the top of the page, then hold Tab and just watch the focus outline march down through your links and buttons.
Keep watching once it gets near the bottom-right corner. If the focus outline ever slides completely behind that chat bubble — vanishes entirely, no ring, no highlight, nothing visible anywhere on screen — you've just found a real, citable accessibility bug. Not a nitpick, not a "nice to have." An actual failure against a named success criterion, sitting on a page you probably shipped months ago without anyone noticing, because nobody testing it ever let go of the mouse.
This one's satisfying to fix precisely because it's so easy to spot once you know to look, and because the fix is usually a CSS tweak, not a rewrite.
The Stat: WCAG 2.2 SC 2.4.11 Focus Not Obscured (Minimum) (Level AA) requires that when a component receives keyboard focus, it must not be entirely hidden by author-created content — such as a sticky chat widget, banner, or footer. The focused item can be partially covered, but some part of it must remain visible. (Source: WCAG 2.2)
Why this bug is so easy to ship by accident
Chat widgets are almost always third-party scripts. Intercom, Drift, Zendesk, a homegrown one, whatever — they inject a fixed-position element into your DOM, usually anchored to bottom: 20px; right: 20px; or similar, sitting on top of everything else with a high z-index so it's always reachable. That's the entire point of the widget: it should float above your content.
The problem is that "float above your content" and "hide a keyboard user's only visual indicator of where they are on the page" are the same behavior from the browser's point of view. Nobody chose to break accessibility on purpose. The widget vendor built a floating box, your team dropped it in, and the box does exactly what it was designed to do — sit on top of whatever's underneath, including, occasionally, a focus ring.
This almost never shows up in normal QA because normal QA uses a mouse. A mouse user never "focuses" the page footer link that happens to sit at the exact pixel coordinates the chat bubble occupies — they click it directly, the click registers, the page navigates, done. It's only a keyboard user tabbing sequentially through every focusable element on the page who runs into the corner where the widget lives and finds their outline swallowed whole.
What SC 2.4.11 actually requires (it's more forgiving than you'd think)
It's worth being precise here, because the criterion isn't "chat widgets must never overlap anything." WCAG 2.2's Focus Not Obscured (Minimum) criterion sets a specific, achievable bar: when an element receives keyboard focus, author-created content (sticky headers, cookie banners, chat widgets, footers) is allowed to partially cover it — just not entirely. As long as some part of the focused element stays visible, you pass. It's a "Minimum" level criterion for a reason: it's the floor, not an aspiration.
That's genuinely good news for fixing this. You don't need to redesign your chat widget or ban it from the bottom-right corner. You just need to make sure it never fully eclipses a focused element — which usually means one of a small number of changes:
- Shrink the widget's collapsed/idle footprint so it occupies less screen real estate.
- Nudge its position a few pixels so it doesn't sit flush against the exact corner where the last tabbable element in your footer or sidebar lives.
- Add scroll-padding or a scroll-margin so the page auto-scrolls a focused element clear of the widget when it's near the edge.
- If the widget can be minimized, make sure minimizing it doesn't just shrink the click target while leaving an invisible hit area still covering the same space (a subtler version of the same bug).
The five-minute test, as a checklist
- Load the page with the chat widget in its normal, docked-open state — don't test it collapsed if collapsed isn't the default.
- Click near the top of the content area, then press Tab repeatedly without touching the mouse.
- Watch every element as focus reaches the bottom of the viewport, especially footer links, "back to top" buttons, and anything in the same corner as the widget.
- If focus ever disappears completely — no ring, no highlight, nothing visible — that element fails SC 2.4.11 while the widget is open.
- Repeat with the widget expanded into a full chat panel, since an expanded panel covers far more of the page than the idle bubble.
- Repeat on mobile viewport widths, where the same widget often takes up a proportionally larger share of a much smaller screen.
| Widget state | Common failure | What to check |
|---|---|---|
| Collapsed bubble | Bubble sits exactly over a footer link's focus ring | Some part of the ring should peek out beyond the bubble's edge |
| Expanded panel | Panel covers the entire lower third of the page, swallowing several focusable rows behind it | Confirm focus never lands on something entirely hidden behind the open panel |
| Minimized state | Visual size shrinks but the invisible click-catching area doesn't | Tab to elements under the "minimized" bubble and check they're actually visible, not just clickable |
You don't have to guess — a real vendor has documented this work
This isn't a theoretical problem that only shows up in an audit checklist. Intercom's own writeup on how they made their Messenger accessible describes the actual engineering work behind fixing keyboard and screen reader issues in a widget used on a huge number of sites — proof that this is a solvable, well-understood category of bug, not an edge case unique to your implementation. If you're using a third-party widget, it's worth checking whether your vendor has published anything similar, and whether you're running a version that includes those fixes.
More broadly, if your team doesn't have a habit of testing with the keyboard alone, WebAIM's guide to keyboard accessibility is the right starting point — the chat widget bug above is just one specific, very findable instance of a much larger pattern: anything that can receive focus needs to stay visible and operable without a mouse, everywhere on the page, in every state.
Fix it today
The nice thing about this bug is that fixing it doesn't require touching the widget's vendor code most of the time — a CSS adjustment to size, position, or scroll-margin on your side is usually enough. Run the five-minute Tab test above on your own homepage this afternoon, and if you find focus disappearing behind your chat bubble, you've already done the hard part: finding it.
It's also worth re-running this same check any time your team changes the widget's default size, adds a promotional banner above it, or switches vendors entirely — a fix that works today can quietly regress the next time someone tweaks the widget's CSS for an unrelated reason, and nobody notices until a keyboard user does. If you'd like a second set of eyes checking for this and similar focus issues across your whole site, a free scan can find focus bugs your chat widget might be causing without you having to Tab through every page by hand.