Sticky Headers, Cookie Banners, and Chat Widgets: Meeting WCAG 2.4.11 Focus Not Obscured (Minimum)

Quick answer: WCAG 2.2 Success Criterion 2.4.11 Focus Not Obscured (Minimum) (Level AA) requires that “when a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” In plain terms: a sticky header, sticky footer, cookie consent banner, or chat-widget launcher can’t be allowed to sit directly on top of whatever a keyboard user just tabbed to and hide it completely. The fix in most cases is a few lines of CSS — reserving scroll space so focus never lands underneath a fixed element — not a redesign.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.2 AA requires for this specific failure mode and how to fix it, not whether a specific implementation carries legal risk.

Why this is its own success criterion

WCAG 2.4.7 Focus Visible (the 2.1 AA criterion requiring a visible focus indicator — see Quietramp’s focus indicators guide) only asks whether a focus style exists and is visible in principle. It says nothing about whether something else on the page is sitting on top of it. A button can have a perfectly styled, high-contrast 2px outline and still be completely invisible to the user tabbing to it, if a fixed-position element is drawn over it at that exact scroll position. WCAG 2.2, published as a W3C Recommendation in October 2023, closed that gap with SC 2.4.11 — a criterion about position, not style.

E-commerce sites are unusually exposed to this because they lean so heavily on persistent, fixed-position UI: sticky headers, sticky “Add to cart” footer bars on product pages, cookie consent banners, and chat-widget launcher bubbles. Any one can obscure a focused element on its own; stacked together (a cookie banner and a sticky header and a chat bubble at once, which is common on a first visit) the obscured area can be significant.

What the criterion actually says — and its two named exceptions

The normative text, quoted directly from the WCAG 2.2 specification and its Understanding document:

“When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.”

Two things to notice in that wording. First, it says entirely hidden — SC 2.4.11 is the AA “Minimum” version, and it’s satisfied as long as some part of the focused component remains visible. A sticky header that covers the top third of a focused button still passes 2.4.11, even though it’s a worse experience than not covering it at all. (There’s a stricter Level AAA sibling, SC 2.4.12 Focus Not Obscured (Enhanced), requiring “no part of the component is hidden by author-created content” — AAA is outside the scope of Quietramp’s AA-focused audits, but it’s worth knowing the stricter version exists if a client wants to go further.)

Second, the criterion explicitly carves out content the user opened, not just content the site author placed. The Understanding document states: “content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.” In other words, a chat window the shopper deliberately clicked open, or a filter panel they expanded, doesn’t count against this criterion as long as they can dismiss or move past it (Escape, a close button, scrolling) without the site forcing them to keep tabbing through it. The failure this criterion targets is specifically persistent, author-placed content the user never asked for and can’t get out from under.

The named failure: sticky headers and footers (Technique F110)

WCAG’s own failure technique, F110, describes this pattern directly: “any ‘sticky’ content that moves with the viewport can potentially obscure other elements on the page, including controls the user may tab to,” with two worked examples quoted verbatim from the technique:

• Sticky footer: “A web page has a sticky footer, an element that stays visible at the bottom of the viewport as the user scrolls the page. The footer is tall enough to completely cover the element in focus as a user tabs down the page.”
• Sticky header: “A web page has a sticky header… tall enough to completely cover the element in focus as a user tabs up the page.”

The e-commerce version of the footer case is extremely common: a product page with a sticky “Add to cart” bar pinned to the bottom of the viewport, and a shopper tabbing down through a long specifications table or set of size/variant options. Each Tab press scrolls the next field into view — except the last few rows disappear behind the sticky bar instead, because nothing told the browser to leave room for it.

The other e-commerce-specific obscuring elements

Sticky headers and footers are the criterion’s named examples, but the same failure mode shows up in other fixed-position UI just as common on e-commerce sites:

• Cookie consent banners. A banner pinned to the viewport on first visit is often the single largest obscuring element on the page, present at the exact moment a keyboard user starts navigating — before they’ve had a chance to dismiss it. See Quietramp’s cookie consent banner guide for the banner’s other, separate issues (unlabeled toggles, non-semantic buttons); this is a distinct failure mode layered on top.
• Chat-widget launcher bubbles. A floating chat-launcher button fixed to a bottom corner can sit directly over the last item in a footer link list, especially on narrower viewports. Quietramp’s live chat widget guide covers the launcher button’s separate labeling requirements; positioning is the concern here.

The fix: reserve scroll space, don’t just hope nothing lines up

The sufficient technique WCAG’s own Understanding document points to is CSS scroll padding — giving the page’s scroll container a permanent buffer so a focused element is never allowed to land underneath a fixed element in the first place:

/* Reserve space at the top of the viewport equal to the sticky header's height,
   so a focused element never scrolls underneath it */
html {
  scroll-padding-top: 80px; /* match the sticky header's actual rendered height */
}

scroll-padding-top is set on the scroll container (here, html) rather than on individual target elements — it defines a permanent “keep-out” margin at the edge of the viewport that applies to every scroll-into-view action, including the browser’s native focus-scrolling behavior. That’s a different mechanism from scroll-margin-top, which is set on the target element itself and is better suited to one-off cases — Quietramp’s focus indicators guide uses that approach for a single sticky-header scenario. Both are valid; scroll-padding-top/-bottom on the scroll container is generally the lower-maintenance fix for something present on every page.

For a sticky footer bar (the “Add to cart” case), the equivalent is scroll-padding-bottom. For a cookie banner or chat launcher that only appears conditionally, a fixed pixel value doesn’t work well — the fix is a CSS custom property updated in JavaScript whenever the overlay mounts, unmounts, or resizes, so the reserved space tracks what’s actually on screen:

html {
  scroll-padding-bottom: var(--obscuring-footer-height, 0px);
}

// Call whenever a cookie banner, sticky bar, or similar element mounts/unmounts/resizes
document.documentElement.style.setProperty(
  "--obscuring-footer-height",
  `${bannerElement.offsetHeight}px`
);

A two-minute manual test

This is a position-based failure, not a code-presence failure, so it’s a fast manual check rather than something that needs specialized tooling:

1. Load the page with any cookie banner or first-visit overlay still showing.
2. Press Tab repeatedly from the top of the page, watching where focus is at each stop.
3. On a product page, keep tabbing to the bottom of the content, past any sticky “Add to cart” bar. Does the last field or button before the footer disappear underneath it?
4. If a chat widget is present, tab through content near its corner and check whether the launcher button sits on top of a link or field.
5. An element that’s partially covered but still partly visible passes SC 2.4.11 at the AA level — only a completely hidden focused element is a failure at the level this article is scoped to.

FAQ

Does this only apply to sticky/fixed-position elements? In practice, yes — the criterion is about anything with position: sticky or position: fixed that stays on screen during scrolling, since that’s the mechanism that lets author content sit on top of whatever the user has scrolled to.

What about a modal dialog that intentionally takes focus, like an age gate? That’s a different, and generally fine, pattern — if a dialog moves keyboard focus into itself on open (the standard WAI-ARIA modal dialog pattern), the user isn’t tabbing to a focus target “underneath” it; focus is inside the dialog, which is fully visible. The failure this article covers is a non-modal, persistently visible element sitting on top of page content the user is still tabbing through.

Is WCAG 2.2 actually relevant if our audit only promises 2.1 AA? WCAG 2.2 became a W3C Recommendation in October 2023 and is the current version of the standard — it doesn’t replace 2.1, it adds nine new criteria on top of it, including this one. It’s worth checking for on any current audit, since sticky UI has only gotten more common since 2.1 was published in 2018.

Get a human-reviewed audit, not just a scan

An automated scanner can check whether a :focus style exists in your CSS. It generally can’t tell you whether that focus indicator actually ends up hidden behind a sticky header on your real, rendered page at a specific scroll position — that’s a positional, context-dependent check a manual keyboard pass catches and a rule-based scan structurally can’t. Quietramp’s audits pair an automated axe-core scan with a manual keyboard review of exactly this kind of issue, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA or WCAG 2.2 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.