Focus Not Obscured: When a Sticky Header Hides the Keyboard

WCAG 2.2 criterion 2.4.11 says a focused element must never be completely hidden by author-created content. Sticky headers, chat widgets, and cookie banners are the usual culprits on storefronts.

Tab through a store with a sticky header and watch the focus indicator slide under it. The link is focused, the browser did its job, and the shopper sees nothing. She keeps tabbing, unsure where she is, and eventually gives up on the keyboard and reaches for the mouse, or leaves. That invisible focus is a failure of WCAG 2.2 Success Criterion 2.4.11, Focus Not Obscured (Minimum), and it is one of the most common Level AA failures on ecommerce sites because it only shows up when a real person uses a keyboard.

The criterion is forgiving in one way and strict in another. At Level AA, a focused element only has to be partially visible. At Level AAA, criterion 2.4.12 demands it be fully visible. The fix is mostly CSS, and it is cheap, but only if you know where the overlap happens.

What the criterion actually requires

Criterion 2.4.11 says that when a user interface component receives keyboard focus, it must not be entirely hidden by author-created content. Partially hidden passes at AA. Completely hidden fails. The distinction matters because a sticky header that covers the top half of a focused link is a pass at AA and a fail at AAA, which is why teams aiming higher than AA need a different fix.

Two exceptions keep the rule honest. Content the user moved over the focused element herself does not count, and content the user opened herself, like a dropdown she can dismiss, does not count either. A cookie banner she never asked for and cannot dismiss without a mouse is not an exception. Neither is a chat widget that re-renders on scroll and re-covers the element the browser just scrolled into view.

Where storefronts hide focus

Sticky headers are first. A header 72 pixels tall with no scroll offset swallows the focused link every time the page scrolls it to the top of the viewport. Sticky footers do the same from below, and they are worse on mobile, where a 360 pixel wide viewport leaves little room for the page to breathe. Cookie banners that sit fixed at the bottom cover the focused element on the first screenful, and a chat bubble parked in the lower corner covers submit buttons on short forms.

Non-modal dialogs are the quieter failure. A newsletter pop-up that opens on entry and lets focus drift behind it will hide focused links completely, which fails 2.4.11 outright. A true modal dialog does not fail by itself, because focus cannot reach the content behind it, but only if the trap works and the background is inert.

The fixes, in order of effort

The cheapest fix is scroll-margin. Add scroll-margin-top to focused elements, set a few pixels larger than the sticky header height, and the browser scrolls the focused element clear of the header automatically. A 72 pixel header wants a scroll-margin-top of around 90 pixels. The same trick works at the bottom with scroll-margin-bottom for sticky footers.

Next, audit z-index and stacking. The focused element should never sit under a decorative layer. If a chat widget must stay visible, give it a lower stacking order than focused content or let it collapse when keyboard focus moves. For dialogs, use the native dialog element with showModal, which puts the dialog in the top layer and makes the rest of the page inert without extra scripts. For custom dialogs, set the inert attribute on the background content while the dialog is open.

Test it the way a keyboard user experiences it. Load the page at 360 pixels and at 1280 pixels, tab through every interactive element including the ones inside dialogs, and watch for any focused element that disappears entirely. Automated scanners mostly miss this criterion because it needs a real focus sequence, so budget twenty minutes of manual tabbing per template.

Related reading: Touch Targets That Are Too Small: Size, Spacing, and the 24 Pixel Floor, Accessible Authentication: Logins That Do Not Test Memory or Puzzle Solving, Accessible Size and Fit Selectors: Swatches Are Radio Groups, Not Pictures.

Frequently asked questions

Does a sticky header always fail WCAG 2.4.11?

No. The criterion fails only when a focused element is completely hidden by author-created content. A header that covers part of a focused link passes at Level AA, though it fails the stricter Level AAA version, 2.4.12, which requires the element to be fully visible.

What is the simplest fix for focus hidden under a sticky header?

Add scroll-margin-top to focusable elements, set slightly larger than the header height. A 72 pixel header usually needs about 90 pixels of scroll margin so the browser scrolls the focused element clear of the header when it receives focus.

Can an automated scanner find focus-obscured failures?

Mostly no. Mainstream scanners have limited coverage of 2.4.11 because it requires tabbing through the page and watching what the browser actually shows. A short manual pass with a keyboard at mobile and desktop widths is the reliable test.

Does a modal dialog fail focus not obscured?

A correct modal does not fail, because focus cannot reach the content behind it. A non-modal dialog that leaves background content focusable while covering it can fail. The native dialog element with showModal handles the layering and inert background for you.