Watching Sticky Help Buttons and Chat Bubbles Cover Focus
Fixed chat bubbles and back to top buttons sit exactly where keyboard focus travels. When they cover the focused element or the checkout button, the failure is visual, positional, and common.
Scroll a product page with the keyboard and sooner or later the focused link disappears behind the chat bubble parked in the bottom corner. The focus is technically visible. It is just visible underneath a fixed button that follows the user down every page, sitting on top of whatever the page puts in that corner.
WCAG 2.4.11, focus not obscured minimum, is a Level AA criterion in WCAG 2.2 aimed at this exact arrangement. When a component receives keyboard focus, at least part of it has to remain visible, not entirely hidden behind author-created content like sticky headers, footers, and chat widgets. The enhanced version, 2.4.12, asks for no part obscured, and while that one is AAA, the gap between them is where most stores actually live.
The corner is contested ground
Bottom right is where chat lives, and it is also where pages put cookie controls, back to top buttons, currency prompts, and the tail end of long forms. Stack two or three fixed elements in that corner and something a user needs is under something else. On mobile viewports the chat bubble alone can cover a fifth of the screen height, and it expands when a proactive message arrives, usually at the moment the shopper is reading the delivery terms at the bottom of the page.
Watch what happens on focus specifically, not just on scroll. Tab to the last links in a footer, the final field of a checkout form, the place order area. If the focused element slides under a fixed bar or bubble and stays there, that is the 2.4.11 failure, and scroll padding on the page is often the simplest repair: give the scroll position enough offset that focused content stops clear of the fixed furniture.
Back to top buttons have their own problem
The back to top control seems harmless and causes a quieter failure. It appears after scrolling, which means it enters the tab order at a position that makes no sense to a keyboard user moving through the page in order, and activating it often moves the scroll position without moving focus, leaving the keyboard user at the bottom of a page they are no longer looking at. If the button exists, activating it should move focus to the top of the main content as well as the view. Most do not.
Some stores would lose nothing by deleting it. Long product pages with good heading structure and a skip link already give keyboard users a faster route up than a floating button does. Watch the analytics before defending it: if the clicks are a rounding error, the button is decoration with an accessibility cost.
Put fixed elements on the regression list
Chat widgets update themselves, outside the theme, on the vendor's schedule. A bubble that behaved in September can grow a proactive popup in November. So fixed elements belong on the same watch rhythm as drawers and banners: after any chat or helpdesk change, tab the full length of a product page and a checkout page and confirm nothing with focus ends up underneath anything fixed. It is a five minute check that catches a class of failure no scanner reports, because scanners do not scroll and tab the way a person does.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Watching Homepage Carousels: Autoplay, Pause, and Focus Order, Watching Checkout Progress Indicators That Screen Readers Miss, and Watching Loyalty Popups That Appear Right After Login.
Frequently asked questions
Which WCAG criterion covers focus hidden behind a chat bubble?
WCAG 2.4.11, focus not obscured minimum, at Level AA in WCAG 2.2. At least part of the focused component must remain visible when author-created content like sticky widgets overlaps it.
How do you fix focus sliding under a sticky bar?
Scroll padding is the usual repair: offsetting where scrolled and focused content stops so it clears the fixed header or footer, alongside checking that the fixed elements are not simply too tall.
What is wrong with most back to top buttons?
They move the view without moving focus, leaving keyboard users stranded at the bottom, and they appear mid-page in the tab order. Activating one should move focus to the top of the main content too.
Can an accessibility scanner find obscured focus?
Not reliably. The failure depends on scrolling and tabbing through a real page at real viewport sizes, so it belongs on a manual watch list, especially after chat widget updates.