2.4.11 Focus Not Obscured (Minimum): what it requires and how to test it

What 2.4.11 requires

When a user interface component receives keyboard focus, other content the site's authors put on the page must not cover all of it. At least part of the focused component has to stay visible. In practice, a link, button or field that someone just tabbed to can't be completely hidden behind a sticky header, sticky footer, cookie banner, chat panel or non-modal dialog. This is a plain-language summary. The normative text, including both notes, is in the W3C Recommendation. The W3C's explanation, examples and techniques are in Understanding 2.4.11 (opens in a new tab) [1][2].

Exceptions and scope:

• Partly hidden passes. At Level AA, only a focused component that is entirely hidden fails. The AAA criterion 2.4.12 Focus Not Obscured (Enhanced) requires that no part of it is hidden.
• User-movable content: if users can reposition a panel or toolbar, only its initial position counts for this criterion.
• User-opened content: content the user opened, such as a chat window, may cover the focused component. That isn't a failure if the user can reveal the focused component without moving focus, for example by pressing Escape to close the panel or by scrolling with the keyboard.
• The component, not the indicator: the criterion looks at the focused component itself. A focus ring drawn outside the component doesn't count toward "not entirely hidden". If the indicator is hidden, the page may separately fail 2.4.7 Focus Visible.
• Semi-transparent or blurring overlays may not entirely hide the component, so they can pass 2.4.11. The focus indicator then has to be evaluated under the overlay for 1.4.11 Non-text Contrast.

Why it matters

Sighted keyboard users have to see where they are. That includes people using switch devices, speech input or on-screen keyboards, and people who zoom in, which shrinks how much of the page fits on screen. Picture someone tabbing down a product page with a sticky "Add to cart" bar at the bottom of the viewport. Focus moves to a link in the page body that sits directly under the bar. The browser scrolls just far enough to put the link in the viewport, but behind the bar, so nothing on screen changes. The person presses Tab again, sees nothing happen, and can't tell where they are or whether the page has stopped responding. The W3C notes that this can make people think the system has become unresponsive [1].

Common failures

Sticky header or footer covers the focused element

This is the W3C's documented failure F110 [3]. The browser scrolls the focused link into the viewport, but the fixed header sits on top of it.

/* Fails: nothing reserves room for the 80px fixed header */
header { position: fixed; top: 0; height: 80px; }

/* Better: scroll padding keeps focused elements clear of it (technique C43) */
header { position: fixed; top: 0; height: 80px; }
html { scroll-padding-top: 96px; }

Cookie banner that stays put while focus moves under it

A non-modal banner pinned to the bottom of the viewport, with focus free to move into content behind it.

<!-- Fails: a fixed, non-modal banner that page content can scroll under -->
<div class="cookie-banner" style="position:fixed;bottom:0">…</div>

<!-- Better: make it modal (focus moves into it and stays until dismissed), -->
<!-- or reserve space: html { scroll-padding-bottom: <banner height>; } -->
<dialog class="cookie-banner" aria-labelledby="cookie-title">…</dialog>

Persistent chat or feedback widget with no keyboard way out

A chat panel the user opened stays open over the page. When focus moves on to page content, there's no Escape key or other keyboard method to reveal the element behind it.

// Fails: the panel only closes with its X button
openChatPanel();

// Better: Escape closes it from anywhere, so the user can reveal the focused element
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && chatPanel.open) closeChatPanel();
});

Dialog-like overlay that doesn't take focus

A popover or drawer appears on top of the page, but focus stays behind it and keeps moving through hidden content. A properly built modal dialog takes focus and keeps it, so it passes [1].

// Fails: the overlay is shown, but focus stays on the page underneath
drawer.hidden = false;

// Better: use a modal dialog, which moves focus inside and keeps it there
drawer.showModal();

Can automated testing check 2.4.11?

No. axe-core 4.13.0 maps no rules to 2.4.11. Whether a focused element is entirely hidden depends on scroll position, viewport size, zoom and which layers are open at the moment focus arrives.

What automation can't decide:

• whether the covering content is author-created, or something the user opened and can dismiss
• whether a panel is user-movable, and so only its initial position counts
• whether the component is entirely hidden or only partly hidden
• whether this holds at every breakpoint and zoom level the page supports

A single-viewport page scan never tabs through the page with sticky layers in place. This agrees with the WCAG 2.2 checklist, which labels 2.4.11 "Needs human or behavioral testing".

A clean automated result is never proof that 2.4.11 is met. See why sites pass axe-core but fail real screen reader users.

How to test it by hand

1. Open the page at a typical desktop width. Accept nothing yet, so any cookie banner or promo bar is still showing.
2. Press Tab from the top of the page through every focusable element. At each stop, check that you can see at least part of the focused component, not just its outline.
3. Pay closest attention near sticky headers, sticky footers, "Add to cart" bars and corner chat buttons. Content scrolling under them is where focus disappears.
4. Open any chat, feedback or side panel, then keep tabbing into the page. If a focused element ends up fully behind the panel, check whether Escape (or scrolling with the keyboard) reveals it without moving focus.
5. Repeat at a narrow width and at 200% and 400% zoom, where sticky elements take up more of the screen.

New to keyboard testing? Start with how to test keyboard-only navigation. For dialogs, see focus management in modals.

How Accessible helps (and where it stops)

Accessible has no dedicated check for 2.4.11 today, and none of its layers claims to detect a focused element hidden behind other content.

• Automated scanning runs axe-core, which maps no rule to this criterion.
• Journeys operate key tasks keyboard-only, and after every keystroke they check where focus landed. That tells you which element has focus at each step, not whether you can see it on screen.
• The keyboard walkthrough in the AI-assistant tools lists every stop when you press Tab from the top of the page. Either list gives you the exact stops to check by eye with sticky elements in view.
• Real-user monitoring includes observers for focus traps, focus lost after route changes, invisible focus and dead-end Tab presses. We don't claim it detects focus hidden behind sticky or overlaid content.

Where it stops: 2.4.11 is a visual judgment made at a specific scroll position, viewport and zoom, so it needs a person. Treat our focus data as a map of where to look, not a verdict. No automated tool, ours included, can certify that a criterion is met.

Related criteria

• 2.4.7 Focus Visible
• 2.4.3 Focus Order
• 1.4.11 Non-text Contrast
• 1.4.10 Reflow
• WCAG 2.2 success criteria checklist

Sources

1. Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum) (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 29, 2026.
2. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 2.4.11 (opens in a new tab). W3C Recommendation. Accessed October 29, 2026.
3. F110: Failure of Success Criterion 2.4.11 due to a sticky footer or header completely hiding focused elements (opens in a new tab) and C43: Using CSS scroll-padding to un-obscure content (opens in a new tab). W3C WCAG 2.2 Techniques. Accessed October 29, 2026.
4. axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 29, 2026.

Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.