Standards · WCAG 2.2

SC 2.4.11 Level AA WCAG 2.2 New in 2.2

Focus Not Obscured (Minimum)

When an element receives keyboard focus, it must not be entirely hidden behind another piece of UI — sticky headers, cookie banners, chat widgets, sticky footers. New in WCAG 2.2 and reshaping how teams build sticky chrome.

What it asks

When a user tabs to a control, at least part of that control must remain visible. The most common failure pattern: a user tabs down past a sticky header, the page auto-scrolls so the focused link lands behind the sticky bar, and the user can no longer see the focus ring. The control still has focus and still responds to Enter, but the user is blind to it.

The SC sets a minimum bar: the focused element can be partially covered, just not entirely. The AAA-level 2.4.12 raises it to “not obscured at all.”

This is one of the four new operability SCs introduced in WCAG 2.2 and has had outsized impact because sticky headers, sticky footers, cookie banners, and chat-widget bubbles are everywhere.

How to meet it

  • Add CSS scroll-margin-top to focusable elements equal to the sticky-header height, so browsers automatically scroll the focused control clear of the header.
  • For sticky footers and chat bubbles, ensure they don’t fully cover any focusable element. Either shrink them on focus, or anchor them in a way that leaves a buffer at the page edge.
  • Cookie banners and dismissible overlays: never make them sticky in a way that traps later tab stops underneath. Either make them modal (with focus trap) or non-blocking.
  • For pages with both a sticky header and a sticky footer, test the tab sequence around the vertical centre of the viewport — that’s where the focused element gets squeezed.
  • Use scroll-padding-top on the scroll container as a fallback for older browsers.
html { scroll-padding-top: 80px; }       /* match sticky header height */
:target, :focus { scroll-margin-top: 80px; }

Common failures

  • Sticky header with no scroll-padding compensation: every tab into the upper half of the viewport hides the focus ring.
  • Cookie consent banner pinned to the bottom that covers the last row of form fields when those fields receive focus.
  • Live chat widget bubble bottom-right that overlaps a “Submit” button in the corner of a form.
  • Promotional sticky bars (Black Friday banners) added by marketing teams without updating scroll-padding tokens.
  • Sticky table headers in dashboards where Tab into the first data row lands behind the header row.

Why it matters

This SC fixes a class of bug that frustrates keyboard users daily but rarely shows up in automated scans — no axe rule can predict at what scroll position a sticky element will overlap a focused one. It also disproportionately affects screen-magnifier users, whose visible viewport is already shrunk to a quarter of the screen, so the sticky element occupies an even larger share.

Expect 2.4.11 to be one of the most-cited new findings in 2026 audit reports. The fix is small (a few CSS tokens) but requires every team that owns a sticky element — header, footer, banner, widget — to coordinate.