2.4.11 Focus Not Obscured (Minimum)

WCAG 2.2 · 2.4.11 AA Operable

What it requires

When a user interface component receives keyboard focus, the focused component must not be entirely hidden by author-created content. Sticky headers, sticky footers, cookie banners, floating chat widgets, and non-modal dialogs commonly overlap the page; this criterion says that at least part of the item with focus has to remain visible so a keyboard user can tell where they are.

This is the minimum (Level AA) bar. The related Level AAA criterion 2.4.12 Focus Not Obscured (Enhanced) goes further and requires that no part of the focused component be hidden. Content the user can dismiss or move out of the way (with the obscuring being a temporary, user-controllable state) is not counted as a failure here.

  • Keyboard-only users who navigate by Tab and need to see the focus indicator to know their position.
  • Low-vision and magnifier users who lose orientation when the focused control scrolls under a sticky banner.
  • People with motor disabilities using switch or voice control, who rely on the visible focus to confirm the right target.
  • People with cognitive or attention differences, who are disoriented when focus seems to "disappear."

How to detect it

Checks for Focus Not Obscured (Minimum)
Check How Finds
Keyboard sweep Tab through every focusable control top to bottom, with sticky bars present. Focused items fully hidden behind sticky/fixed regions.
Scrolled state Repeat after scrolling so headers/footers are pinned over content. Items obscured only once the page is mid-scroll.
Overlays Open cookie banners, chat widgets, and non-modal popups, then Tab. Floating layers covering the focused element.
Zoom / reflow Test at 200%–400% zoom where overlays grow relative to the viewport. Obscuring that only appears at high zoom.
Automated tools Run axe or similar. Largely not detectable automatically — this needs manual keyboard testing.

How to fix it

  1. Identify every persistently positioned layer (position: sticky or fixed): headers, footers, banners, chat bubbles.
  2. Reserve space for them so focused content is not scrolled underneath — the most robust technique is scroll-padding on the scroll container equal to the sticky region's height.
  3. Make persistent overlays dismissible (a close control) so users can remove the obstruction.
  4. Re-test the full keyboard sweep, scrolled and at high zoom, to confirm at least part of each focused control stays visible.

Setting scroll-padding-top to the sticky header height keeps anchored focus targets clear of the bar:

/* Sticky header is 4rem tall */
html {
  scroll-padding-top: 4rem;    /* keep focused targets below the header */
  scroll-padding-bottom: 3rem; /* and above a sticky footer */
}

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule that proves 2.4.11. Whether a focused element is hidden by a sticky header, footer, or overlay depends on runtime layout and scroll position, so this criterion needs manual review using the console check and steps below.

Run this in the browser console

focus-not-obscured-check.js 
// Read-only: lists fixed/sticky elements that could overlap focused content.
const stuck = [...document.querySelectorAll('*')].filter(el => {
  const p = getComputedStyle(el).position;
  return p === 'fixed' || p === 'sticky';
});
stuck.forEach(el => { el.style.outline = '2px dashed red'; });
console.table(stuck.map(el => ({
  tag: el.tagName.toLowerCase(),
  id: el.id || '',
  cls: el.className || '',
  zIndex: getComputedStyle(el).zIndex,
  rect: JSON.stringify(el.getBoundingClientRect())
})));
console.log('Now Tab through the page and watch for focus hidden behind these.', stuck);

What to check manually: Tab through the page at several scroll positions and confirm the focused element is never fully covered by a sticky header/footer or a cookie/chat overlay. No script can confirm the element stays at least partially visible while focused.