Reviewed November 8, 2026

Focus Not Obscured: The WCAG 2.4.11 Failure Hiding Under Your Sticky Header

A keyboard user presses Tab, the browser scrolls the next control into view, and it lands directly behind your sticky header. They cannot see what is focused or where they are. They press Tab again and the focus indicator is gone, somewhere under the banner.

WCAG 2.2 added a criterion for exactly this failure, and it is one of the most common violations on storefronts, because almost every store has a sticky header, a cookie banner, or a chat widget sitting on top of the page. The fix is usually a single line of CSS, which makes it one of the cheapest AA failures to leave in place.

What the criterion actually says

WCAG 2.4.11 Focus Not Obscured (Minimum) is Level AA, new in WCAG 2.2, which became a W3C Recommendation on October 5, 2023. The text is short: when a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content. Entirely is the operative word. At AA, a focused button that is half under the sticky header passes. One that is completely under it fails.

The obstruction has to come from content you control: sticky toolbars, fixed banners, sticky footers, chat widgets that stay open. Content the user opened, such as an expanded menu, does not count as obscuring focus if the user can reveal the focused element without moving focus, for example by pressing Escape to close it. Content the user can move around only counts in its initial position.

The W3C documents this as failure F110: a sticky header or footer that completely hides the focused element. It is a documented failure because it is so common, not because it is hard to fix.

Where it shows up on storefronts

The sticky header is the usual culprit, and it bites hardest when tabbing backwards. Tabbing forward, the focused element lands at the bottom edge of the viewport, right under the cookie bar. Tabbing backwards with Shift and Tab, it lands at the top edge, right under the sticky header. Both directions fail, and both are invisible to a mouse user.

The chat widget is the second culprit. An Intercom-style bubble in the bottom corner covers the focused Submit button on a mobile viewport, and the user tabs, the focus indicator disappears under the widget, and keyboard navigation dies. The cookie consent banner does the same thing when it re-renders on scroll and re-covers the focused element after the browser has scrolled it into view.

The test takes two minutes. Load the page at 360 pixels wide and at 1280 pixels wide, press Tab from the top, and watch. Any focused element that is 100 percent hidden by sticky content is a failure, and any page with a sticky header, a cookie bar, and a chat widget almost certainly has one.

The fix, in one line

Set scroll-padding-top on the scroll container, usually the root element, to the height of the sticky header. The browser then treats that region as covered, and anything scrolled into view, including by focus, lands inside the visible area. A sticky footer gets scroll-padding-bottom the same way. The W3C recommends this as technique C43.

For elements that need more room than the header height, scroll-margin-top on the targets works the same way: a 72 pixel sticky header gets 90 pixels of scroll margin, so a focused link always sits visibly below it. Keep the banner z-index below focused elements, and make sure the cookie banner does not re-render over the focus after the scroll. That is the whole fix, and it is why leaving this criterion failed is hard to defend.

Frequently asked questions

What does WCAG 2.4.11 require?

When a user interface component receives keyboard focus, it must not be entirely hidden by content the author created, such as a sticky header, a sticky footer, a cookie banner, or a chat widget. Partially hidden passes at Level AA. Completely hidden fails.

How is 2.4.11 different from 2.4.12?

2.4.11 is Level AA and allows partial obstruction. 2.4.12 is Level AAA and allows no obstruction at all: no part of the focused component may be hidden. Meeting 2.4.12 automatically meets 2.4.11.

What is the usual fix for a sticky header hiding focus?

Set scroll-padding-top on the scroll container to the height of the sticky header, or scroll-margin-top on the focusable elements. The browser then stops scrolling short of the sticky region, so a focused element always lands in the visible area.

Do automated accessibility checkers catch this?

Usually not. Most automated tools do not tab through the page and watch where focus lands, so 2.4.11 failures survive audits that pass everything else. The test is manual: tab through the page at 360 pixels and 1280 pixels wide and watch for focus disappearing under sticky content.