WCAG 2.4.11: Focus Not Obscured (Minimum)
A keyboard user presses Tab, the browser scrolls the next control into view — and it lands directly behind your sticky header, completely hidden. They cannot see what is focused or where they are. New in WCAG 2.2, criterion 2.4.11 closes that gap, and the fix is usually a single line of CSS: scroll-padding.
The success criterion, in full
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Why this criterion exists
Sticky headers are everywhere. So are cookie banners pinned to the bottom of the screen, "back to top" buttons, and live-chat bubbles floating in a corner. For someone using a mouse, these never get in the way — you click exactly where you want and the page does not move. For someone navigating by keyboard, the browser does the scrolling for you, and it has no idea your header is sticky.
So when a keyboard user tabs onto a link near the top of the viewport, the browser dutifully scrolls it into view — flush against the top edge, right where your position: sticky header is sitting. The focused element disappears underneath it. The user cannot see the focus indicator, cannot read the control, and has no way to know what activating it will do. WCAG 2.2 added 2.4.11 precisely because this pattern is so common and so easy to ship without noticing. The good news: once you know to look for it, the fix is almost always trivial.
What 2.4.11 actually requires
There are three testable ideas behind the criterion. Get these right and keyboard users can always see what they have focused.
1. When an element receives focus, it must not be entirely hidden
At least part of the focused component has to remain visible — a sticky header or overlay covering it completely is a failure.
2.4.11 is the 'Minimum' level: the focused element is allowed to be partially covered, but it cannot be 100% obscured by other content the author placed on top. If a keyboard user presses Tab and the element they just moved to is hidden behind a sticky header, a cookie banner, or a floating chat widget, they have no idea where they are. The criterion guarantees that something of the focused item stays on screen.
2. It applies to author-created overlapping content
The obstruction must come from content you control — sticky toolbars, banners, sticky footers — not from the user's own browser tools.
The element being hidden by a sticky header you built is in scope. The element being hidden because the user opened the browser's find-on-page bar, or a non-modal author-opened layer the user can dismiss, is treated differently. In practice, the realistic, common failures are author UI: position: sticky / fixed headers and footers, persistent cookie consent bars, 'back to top' buttons, and live-chat bubbles that float over scrolled content.
3. Both keyboard focus and the new pointer interaction count
The criterion is about the component that receives keyboard focus; the fix is usually a CSS scroll change, not JavaScript.
When focus moves via the keyboard, the browser scrolls the element into view. The bug is that the browser scrolls it flush against the top or bottom edge, directly underneath a sticky bar. The reliable fix is to reserve space for that bar with scroll-padding on the scroll container (or scroll-margin on the targets) so the browser stops short of the sticky region, leaving the focused element fully visible.
The rule of thumb: if you have anything pinned over the page with position: sticky or position: fixed, you almost certainly need scroll-paddingon the scroll container equal to its size — scroll-padding-top for a sticky header, scroll-padding-bottom for a sticky footer.
What obscures focus in the real world
Almost every 2.4.11 failure comes from one of these patterns. If your site uses any of them, test it with the keyboard:
Sticky / fixed headers
The single most common cause. A nav bar pinned to the top covers links and buttons as the user tabs to them near the top of the viewport.
Sticky footers & toolbars
Pinned bottom bars (formatting toolbars, action bars) hide elements the user tabs to near the bottom of the scroll area.
Cookie & consent banners
Persistent banners that stay on screen while the user navigates can cover focused controls until they are dismissed.
Floating widgets
"Back to top" buttons, live-chat bubbles, and slide-in promos float over scrolled content and can land on top of the focused element.
Watch the partial case too: 2.4.11 only fails when the element is entirelyhidden, but an element that is mostly covered — with just a sliver showing — is a poor experience and may fail the AAA criterion 2.4.12. Aim to keep the whole focused element, not just a corner of it, visible.
Minimum (2.4.11) vs. Enhanced (2.4.12)
- 2.4.11 Focus Not Obscured (Minimum) — Level AA: the focused component must not be ENTIRELY hidden. Partial obstruction passes. This is the conformance bar most teams target.
- 2.4.12 Focus Not Obscured (Enhanced) — Level AAA: NO part of the focused component may be hidden by author content. Stricter, and the right goal where you can manage your sticky regions tightly.
- Both are new in WCAG 2.2 and both are fixed the same way — with scroll-padding / scroll-margin sized to your sticky regions. Meeting the Enhanced version automatically meets the Minimum.
Because the fix is the same, it usually costs nothing extra to clear the focused element fully and satisfy the Enhanced criterion. Pair this with a strong focus ring per 2.4.7 Focus Visible so the indicator is both present and unobstructed.
Scope and edge cases
The criterion is scoped to author-created obstructions. These clarifications keep you from misapplying it.
- If the obstructing content can be revealed and dismissed by the user without moving focus (for example, the user collapsed a sticky banner), and it is the user — not the author — keeping it open, the criterion is satisfied even when it would otherwise cover the focus.
- Where the user agent (the browser) itself causes the obstruction — such as the browser's own find bar or autofill dropdown — the author is not responsible under 2.4.11.
- 2.4.11 is the Level AA 'Minimum': partial obstruction is permitted. The stricter 2.4.12 Focus Not Obscured (Enhanced), Level AAA, requires that no part of the focused element is hidden at all.
Code examples
The one-line fix: scroll-padding for a sticky header
Set scroll-padding-top on the scroll container (usually the root) to the height of your sticky header. The browser will stop scrolling short of that region, so a focused element never lands underneath it.
/* Sticky header is 5rem tall */
header.site-nav {
position: sticky;
top: 0;
height: 5rem;
}
/* Reserve that space when the browser scrolls
a focused element (or anchor target) into view */
:root {
scroll-padding-top: 5rem;
}Sticky footer: reserve space at the bottom
A pinned bottom bar hides elements the user tabs to near the bottom of the page. scroll-padding-bottom handles it the same way.
:root {
/* Header 5rem + footer toolbar 4rem */
scroll-padding-top: 5rem;
scroll-padding-bottom: 4rem;
}Per-element control with scroll-margin
When you cannot set padding on the scroll container, put scroll-margin-top on the focusable targets instead. This is also handy for individual anchor targets like section headings.
/* Keep focusable controls clear of the sticky header */
a, button, input, select, textarea, [tabindex] {
scroll-margin-top: 5rem;
}Dynamic header height with a CSS variable
If your header height changes (it shrinks on scroll, or differs by breakpoint), drive scroll-padding-top from a custom property you update in one place.
:root {
--sticky-header-height: 5rem;
scroll-padding-top: var(--sticky-header-height);
}
@media (min-width: 1024px) {
:root { --sticky-header-height: 6.5rem; }
}Common mistakes
- Shipping a sticky or fixed header with no scroll-padding, so every element tabbed to near the top of the viewport lands hidden underneath it — the classic failure.
- Setting scroll-padding-top smaller than the actual header height, leaving the focused element partially under the bar; size it to the full rendered height.
- Forgetting sticky footers, cookie banners, and floating chat widgets — only fixing the header and missing the other overlays that obscure focus.
- Hard-coding a pixel value that drifts out of sync when the header height changes responsively; drive it from a single CSS variable or matched value.
- Assuming a strong focus ring (2.4.7) is enough — a visible indicator drawn under a sticky header is still invisible to the user.
- Only testing with a mouse. Mouse users never trigger the browser scroll-into-view that exposes this bug; you must test with Tab.
- Relying on JavaScript scroll hacks (window.scrollBy after focus) that fight the browser and behave inconsistently, when scroll-padding is the native, reliable fix.
- Overlapping content with a high z-index that covers focus on small screens only — always retest at mobile widths where sticky bars take up more of the viewport.
How to test for 2.4.11
- 1
Tab through the entire page
Press Tab from the top and watch where each focused element lands. The bug appears the moment a control scrolls into view directly beneath a sticky header or footer.
- 2
Scroll, then tab back up
Scroll partway down the page, then Shift+Tab toward the top. Elements near the sticky header are the ones most likely to be covered.
- 3
Check every sticky and floating layer
Test with the cookie banner showing, the chat widget open, and any sticky footer present. Each overlay can obscure focus independently.
- 4
Test at mobile widths
Sticky bars occupy a larger share of a small viewport, so an element that is clear on desktop can be fully covered on a phone. Resize and re-tab.
- 5
Confirm the focus indicator is fully visible
It is not enough that part of the element shows — the focus ring should be visible so the user can see exactly what is focused. This ties 2.4.11 to 2.4.7 Focus Visible.
This is a manual, keyboard-driven check — automated scanners rarely catch it because they do not simulate tabbing with sticky regions rendered. Build the habit into your keyboard accessibility testing routine, and scan a live page with the URL Accessibility Auditor.
Related success criteria
2.4.7 Focus Visible — AA
Requires a visible focus indicator. 2.4.11 ensures that indicator is not hidden behind sticky content — the two together guarantee the user can always see what is focused.
2.4.3 Focus Order — A
Focus must move in a meaningful order. 2.4.11 makes sure that as focus follows that order, each element it reaches stays visible rather than disappearing under an overlay.
2.1.1 Keyboard — A
All functionality must be keyboard operable. 2.4.11 protects that keyboard experience by keeping the currently focused control on screen as the user tabs through the page.
2.5.8 Target Size (Minimum) — AA
Another new-in-2.2 criterion. Where 2.5.8 keeps targets big enough to hit, 2.4.11 keeps the focused target visible — both improve pointer and keyboard ergonomics.
Browse every criterion in the WCAG Success Criteria hub or work through the full WCAG 2.2 checklist. For the surrounding focus-management practices, see the Keyboard Accessibility guide.
Frequently asked questions
What does WCAG 2.4.11 Focus Not Obscured (Minimum) require?
WCAG 2.4.11 (Level AA, new in WCAG 2.2) requires that when a user interface component receives keyboard focus, it is not entirely hidden by author-created content such as a sticky header, sticky footer, cookie banner, or floating widget. At least part of the focused element must remain visible. It is the 'Minimum' version — partial covering is allowed; the AAA version, 2.4.12, requires the focused element be fully visible.
How do I fix a sticky header that hides the focused element?
Add scroll-padding-top to the scrolling container (usually the :root / html element) equal to the height of your sticky header, or set scroll-margin-top on the focusable targets. This tells the browser to stop scrolling short of the sticky region when it brings a focused element into view, so the element lands below the header instead of underneath it. For example, html { scroll-padding-top: 5rem; } if your sticky header is 5rem tall. The same approach with scroll-padding-bottom handles sticky footers.
What is the difference between 2.4.11 and 2.4.12?
Both are 'Focus Not Obscured', new in WCAG 2.2. 2.4.11 Focus Not Obscured (Minimum) is Level AA and allows the focused element to be partially covered — only complete obstruction fails. 2.4.12 Focus Not Obscured (Enhanced) is Level AAA and is stricter: no part of the component that receives focus may be hidden by author content. Meet 2.4.11 first for AA conformance; aim for 2.4.12 when you want a stronger guarantee.
Does scroll-padding actually satisfy 2.4.11?
Yes, in the most common case. The typical failure is that the browser scrolls a newly focused element flush to the viewport edge, directly under a sticky bar. scroll-padding on the scroll container (or scroll-margin on the focusable elements) reserves space for the sticky bar so the focused element is brought to rest in the visible area instead. It is a CSS-only fix that works for keyboard Tab navigation and in-page anchor jumps alike. Always verify by tabbing through the page with the sticky element in place.
Is 2.4.11 only about sticky headers?
No. Sticky and fixed headers are the most common cause, but any author content layered over the page can obscure focus: persistent cookie-consent banners, sticky footers and toolbars, 'back to top' buttons, live-chat bubbles, slide-in promos, and notification trays. Any of these can sit on top of a focused control after the user tabs to it. Test every one of them with keyboard navigation, because each can independently cause a 2.4.11 failure.
How is 2.4.11 related to 2.4.7 Focus Visible?
They are complementary. 2.4.7 Focus Visible (Level AA) requires that a visible focus indicator exists. 2.4.11 Focus Not Obscured ensures that the focused element — and therefore its indicator — is not hidden behind other content. A page can pass 2.4.7 by drawing a strong focus ring yet still fail 2.4.11 if a sticky header covers the focused element so the user never sees that ring. You need both: a visible indicator, and nothing covering it.