WCAG 2.4.12: Focus Not Obscured (Enhanced)
A keyboard user’s only sense of “where am I?” is the focused element. This criterion — the strict AAA sibling of 2.4.11 — requires that no part of the focused component is hidden by content you placed on the page. Not half-covered by a sticky footer, not clipped under a fixed header: fully visible, always.
The success criterion, in full
When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.
Compare the Level AA wording in 2.4.11: “…the component is not entirelyhidden.” The Enhanced criterion deletes the tolerance for partial covering. “Author-created content” scopes it to things you put in the page — sticky bars, banners, widgets — not the user’s own browser UI.
Who this helps and why
Sighted keyboard users — people with motor disabilities who cannot use a mouse, power users, switch-device users — operate a page by watching the focus indicator move as they press Tab. When the browser scrolls the next focused element flush against the viewport edge and a sticky bar sits on top of it, the user loses the thread: they cannot see what is focused, read its label, or judge what pressing Enter will do.
The Enhanced criterion matters because partialvisibility is often not enough in practice. If a form field’s label and error message are under the sticky footer and only its top border peeks out, a user with low vision or a cognitive disability still cannot use it. Full visibility removes the guesswork entirely.
It also protects magnification users, for whom sticky regions consume a huge share of the zoomed viewport, and it compounds with 2.4.7 Focus Visible — an excellent focus indicator is worthless while it is parked underneath a cookie banner.
2.4.11 vs 2.4.12: one word of difference
2.4.11 Focus Not Obscured (Minimum) — AA
The focused component must not be entirely hidden. Partial covering passes: if any visible fragment of the element remains, the AA bar is met.
2.4.12 Focus Not Obscured (Enhanced) — AAA
No part of the focused component may be hidden. The entire element must remain visible and uncovered whenever it holds keyboard focus.
Concrete example: a 48px-tall “Subscribe” button scrolls into view beneath a 40px sticky header, leaving an 8px strip visible. 2.4.11: pass (not entirely hidden). 2.4.12: fail (part of it is hidden). Same page, same CSS — the AAA criterion simply refuses the compromise.
The good news: the engineering fix is identical for both, and once you reserve scroll space for your sticky regions correctly, you meet the Enhanced criterion at no extra cost. That is why teams that fix 2.4.11 with scroll-padding rather than with “a sliver still shows” arguments get AAA behaviour for free.
The usual culprits
Sticky headers and nav bars
The browser scrolls the focused element flush to the top of the viewport — directly underneath the fixed header.
Sticky footers and action bars
Bottom-anchored toolbars and 'Accept / Continue' bars cover elements the browser scrolls flush to the bottom edge.
Cookie and consent banners
Large persistent banners — especially bottom sheets — sit over whole rows of focusable content until dismissed.
Chat bubbles and floating buttons
Fixed-position chat launchers, 'back to top' buttons, and promo toasts hover over content in the corner they occupy.
Code examples
Reserve scroll space with scroll-padding
Tell the browser how much of the viewport your sticky regions consume. Focus-driven scrolling then stops short of them, keeping the focused element fully clear.
/* ✗ Nothing reserved: focused elements scroll under the bars */
.site-header { position: sticky; top: 0; height: 64px; }
.action-bar { position: fixed; bottom: 0; height: 72px; }
/* ✓ Focus scrolling stops clear of both sticky regions */
html {
scroll-padding-top: 64px; /* height of sticky header */
scroll-padding-bottom: 72px; /* height of fixed footer */
}Or set scroll-margin on focusable targets
When you cannot style the scroll container — embedded contexts, third-party shells — scroll-margin on the elements themselves achieves the same clearance.
/* ✓ Every focusable element keeps clear of the sticky bars */
a, button, input, select, textarea, [tabindex] {
scroll-margin-top: 64px;
scroll-margin-bottom: 72px;
}Design overlays out of the collision path
CSS clearance handles scroll-driven overlap. For persistent floating widgets, the sturdier answer is layout: let them occupy reserved space instead of hovering over content.
<!-- ✗ Banner floats over the page, covering focusable rows -->
<div class="cookie-banner" style="position: fixed; bottom: 0">…</div>
<!-- ✓ Banner participates in layout; nothing renders beneath it -->
<body style="display: flex; flex-direction: column; min-height: 100dvh">
<main style="flex: 1">…</main>
<div class="cookie-banner">…</div> <!-- in flow, not floating -->
</body>Common failures
- Sticky headers with no scroll-padding, so tabbing backwards scrolls each newly focused element under the header.
- Fixed bottom action bars ('Save', 'Accept cookies') that cover the lower portion of focused form fields and their error messages.
- Chat launchers and 'back to top' buttons overlapping the last focusable items in a column — passes 2.4.11 by a sliver, fails 2.4.12.
- Non-modal toast notifications that appear over the element the user is currently focused on.
- Autocomplete or mega-menu panels that stay open and cover elements as focus moves beyond them.
- Only testing forward tabbing from the top of the page — top-edge obscuring typically appears when tabbing in reverse (Shift+Tab).
- Reserving scroll space for the header but forgetting the sticky footer, or vice versa.
How to test for 2.4.12
- 1
Inventory the floating layers
List everything with position: sticky or fixed — headers, footers, banners, chat widgets, toasts. These are the only things that can cause a failure, so know where they are before you start tabbing.
- 2
Tab through the entire page
Press Tab from the top of the document to the end, watching each focused element. Every time focus lands near a sticky region, check: is any pixel of the element (not just its indicator) covered?
- 3
Tab backwards too
Shift+Tab from the bottom of the page upward. Reverse tabbing scrolls elements against the top edge, which is exactly where sticky headers live — most failures only appear in this direction.
- 4
Repeat with overlays active
Re-run the pass with the cookie banner undismissed, the chat widget loaded, and any promotional toasts visible. Test at several viewport sizes and at 200%+ zoom, where sticky regions eat proportionally more of the screen.
- 5
Apply the stricter AAA judgment
For 2.4.11 you asked 'is anything still visible?' For 2.4.12 ask 'is everything visible?' Any partial covering of the focused component by author content — even a few pixels — is a failure at this level.
This is a purely manual, visual test — automated scanners cannot yet reliably detect focus obscuring. Fold it into your keyboard pass alongside 2.4.7 Focus Visible checks, and track it in the WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 2.4.12 Focus Not Obscured (Enhanced) require?
It requires that when a user interface component receives keyboard focus, no part of the component is hidden by author-created content. Where the Level AA version (2.4.11) tolerates partial covering as long as some of the element remains visible, the AAA version demands the entire focused element stay visible — nothing clipped behind a sticky header, floating footer, cookie banner, or chat widget. It is one of the success criteria introduced in WCAG 2.2.
What is the exact difference between 2.4.11 and 2.4.12?
One word of scope. 2.4.11 Focus Not Obscured (Minimum), Level AA, says the focused component must not be entirely hidden — if even a sliver remains visible, it passes. 2.4.12 Focus Not Obscured (Enhanced), Level AAA, says no part of the focused component may be hidden — the whole element, including its focus indicator area, must be on screen and uncovered. A button whose bottom half slides under a sticky footer passes 2.4.11 and fails 2.4.12.
Does 2.4.12 apply to content the user opened themselves?
The criterion targets author-created content that overlaps the focused element — sticky bars, banners, and widgets you placed in the layout. Content the user can reposition or dismiss is treated pragmatically: if the user opened a movable panel that happens to cover a focused control, the understanding documents for the focus-obscured criteria treat user-movable and user-dismissible content more leniently. The realistic failures you must engineer away are your own persistent overlays.
Is a semi-transparent overlay over the focused element a pass?
For 2.4.11 the understanding document notes that content is not considered 'hidden' by an overlay that is sufficiently transparent for the component to still be perceived. For 2.4.12's stricter 'no part hidden' bar, the safe engineering interpretation is: do not let anything you author sit on top of a focused element at all. If a translucent scrim leaves the element clearly perceivable it may be arguable, but designing so the question never arises is both easier to verify and better for users.
How do I fix sticky-header focus obscuring with CSS?
Reserve space for the sticky regions in the scroll calculation. Set scroll-padding-top (and scroll-padding-bottom for sticky footers) on the scroll container — usually html — equal to the height of the fixed bars, or set scroll-margin on focusable targets. When the browser scrolls a newly focused element into view, it will stop short of the sticky region instead of tucking the element underneath it. This one- or two-line CSS fix resolves the vast majority of 2.4.11 and 2.4.12 failures simultaneously.
Do I need to meet 2.4.12 for legal compliance?
Generally no — laws and procurement standards reference WCAG Level AA, which includes 2.4.11 but not 2.4.12. However, the fix for both is usually identical (scroll-padding, or not overlapping content in the first place), so once you address the AA criterion properly you often meet the AAA one for free. Fully visible focus also compounds with 2.4.7 Focus Visible and 2.4.13 Focus Appearance to make keyboard operation genuinely comfortable rather than merely possible.
Related Success Criteria
A mechanism is available to bypass blocks of content that are repeated.
Web pages have titles that describe topic or purpose.
Focusable components receive focus in an order that preserves meaning.
The purpose of each link can be determined from link text or context.
More than one way is available to locate a page within a set of pages.