WCAG 2.4.12 Focus Not Obscured (Enhanced): Keep Focus Fully Visible

What This Criterion Requires

WCAG 2.4.12 Focus Not Obscured (Enhanced) is a Level AAA success criterion introduced in WCAG 2.2. It requires that when a user interface component receives keyboard focus, no part of the component is hidden by author-created content. It is the strict sibling of 2.4.11 Focus Not Obscured (Minimum), the Level AA criterion that only requires the focused element to remain partially visible. Under the enhanced criterion, a sticky header that clips even the top few pixels of a focused link, or a cookie banner that overlaps one corner of a focused button, is a failure - the entire component, including its focus indicator, must stay in view. Meeting it means designing layouts where fixed-position elements never overlap focusable content: reserving space for sticky headers and footers with scroll-padding sized to clear them completely, keeping floating widgets out of content areas, and ensuring scripted focus movement scrolls the whole target into an unobstructed position. Teams targeting AA conformance only need 2.4.11, but treating 2.4.12 as the design goal produces interfaces where keyboard users never lose sight of where they are.

Why It Matters

Partial visibility - the AA bar - still leaves real problems. If a sticky header covers the top half of a focused button, a keyboard user may see a sliver of highlight but cannot read the button's label, so they know something has focus without knowing what. People with low vision who zoom the page magnify the problem: overlays occupy proportionally more of the viewport, and a 'partially visible' element may be reduced to a few visible pixels. People with cognitive disabilities lose context when most of the focused control is hidden, and users of high-visibility focus indicators (thick outlines set in their OS or extensions) find the indicator itself clipped by the very chrome that obscures the element. The enhanced criterion removes the ambiguity entirely: the whole component stays visible, so focus is always identifiable at a glance. Because the fixes - scroll padding that fully clears fixed elements, overlays that do not sit over content - are the same techniques as the minimum version with stricter measurements, teams already meeting 2.4.11 can usually reach 2.4.12 by adjusting values rather than redesigning.

Common Failures and How to Fix Them

header.sticky {
  position: sticky;
  top: 0;
  height: 72px;
}
html {
  /* Exactly header height: outline still clips */
  scroll-padding-top: 72px;
}

header.sticky {
  position: sticky;
  top: 0;
  height: 72px;
}
html {
  /* Header height + outline width + safety margin */
  scroll-padding-top: 88px;
}
:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
  /* Per-element guarantee, works in scroll containers too */
  scroll-margin-top: 88px;
  scroll-margin-bottom: 16px;
}

.cookie-banner {
  position: fixed;
  bottom: 0;
  width: 100%;
  min-height: 96px;
}
/* Body padding tuned to desktop banner height only */
body { padding-bottom: 96px; }

.cookie-banner {
  position: fixed;
  bottom: 0;
  width: 100%;
  min-height: 96px;
}
/* Measure the real banner height and reserve it */
body { padding-bottom: calc(var(--banner-height, 96px) + 24px); }
html { scroll-padding-bottom: calc(var(--banner-height, 96px) + 24px); }
/* JS: keep --banner-height in sync */
// new ResizeObserver(([e]) =>
//   document.documentElement.style.setProperty(
//     '--banner-height', e.contentRect.height + 'px')
// ).observe(document.querySelector('.cookie-banner'))

.chat-launcher {
  position: fixed;
  bottom: 16px;
  right: 16px;
  /* Sits over the content column on narrow screens */
}

/* Reserve a lane for the widget so it never overlaps content */
.page-content {
  max-width: calc(100vw - 120px);
}
@media (max-width: 720px) {
  /* Or move the launcher into the layout flow on small screens */
  .chat-launcher { position: static; margin: 16px auto; }
}
html {
  scroll-padding-bottom: 96px;
}

How to Test

1. Tab through every interactive element and confirm each focused component - including its focus outline - is completely visible, with no pixel hidden behind sticky headers, footers, banners, or widgets.
2. Repeat the pass at 200% and 400% zoom and at narrow viewport widths, where fixed overlays occupy proportionally more space and full obscuring becomes far more likely.
3. Open every overlay state (cookie banner visible, chat expanded, promo bar shown) and tab through nearby content in each state; the criterion applies to whatever author-created content is on screen.
4. Where scripted focus moves (after form errors, in single-page apps), verify the focus target scrolls into a fully unobstructed position, not merely into the viewport.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

• Wordpress Accessibility Checklist
• Shopify Accessibility Checklist
• Squarespace Accessibility Checklist
• Wix Accessibility Checklist

Further Reading

• Keyboard Navigation Testing
• Sticky Header Accessibility
• Cookie Consent Banner Accessibility

Related WCAG Criteria

• WCAG 2.4.11
• WCAG 2.4.7
• WCAG 2.4.13