2.4.11 Focus Not Obscured (Minimum)

What this rule means

WCAG 2.4.11 is a new criterion introduced in WCAG 2.2 that addresses a common modern web pattern: sticky headers, footers, cookie banners, and overlays that cover focused elements. When a component receives keyboard focus, at least part of it must remain visible — it must not be entirely hidden behind other content created by the page author.

This is the minimum requirement — at least some part of the focused component must be visible. The enhanced version (2.4.12) requires that the focused component is fully visible. Note that this criterion only applies to content controlled by the author, not user-agent features like browser toolbars.

Why it matters

Sticky headers, fixed-position cookie banners, and chat widgets are ubiquitous on modern websites. When a keyboard user tabs to an element that is positioned behind one of these sticky elements, they cannot see what they are interacting with. This is equivalent to having a piece of paper covering part of a form while trying to fill it out — frustrating and error-prone.

This problem disproportionately affects keyboard users because mouse users can scroll to reveal obscured elements, but keyboard focus does not automatically scroll the page to ensure visibility. Users with motor impairments, low vision, and cognitive disabilities are especially impacted.

Related axe-core rules

There are currently no automated axe-core rules for 2.4.11. This criterion requires manual testing with keyboard navigation.

How to test

1. Navigate the entire page using Tab. At each focused element, check if any sticky or fixed-position content covers it.
2. Pay special attention to elements near the top and bottom of the viewport where sticky headers and footers appear.
3. Trigger cookie banners, chat widgets, and notification bars, then tab through the page to check for obscured focus.
4. Resize the browser window to a smaller size and repeat the test — obscured focus is more likely in smaller viewports.

• Check that scroll-padding or scroll-margin is used to account for sticky elements when focus causes scrolling.

How to fix

Use CSS scroll-padding to prevent sticky elements from obscuring focused content, and ensure overlays do not block interactive elements.

Scroll padding for sticky headers

/* Prevent sticky header from covering focused elements */
html {
  scroll-padding-top: 80px; /* Height of sticky header */
}

/* If you have a sticky footer too */
html {
  scroll-padding-top: 80px;
  scroll-padding-bottom: 60px;
}

/* Sticky header styles */
.site-header {
  position: sticky;
  top: 0;
  z-index: 100;
  height: 80px;
}

Cookie banner that does not obscure focus

<!-- Cookie banner that pushes content up instead of overlaying -->
<div class="cookie-banner" role="dialog" aria-label="Cookie consent">
  <p>We use cookies to improve your experience.</p>
  <div>
    <button>Accept all</button>
    <button>Reject non-essential</button>
    <a href="/privacy">Cookie policy</a>
  </div>
</div>

<style>
.cookie-banner {
  position: sticky;
  bottom: 0;
  z-index: 100;
  padding: 1rem;
  background: #1a1a2e;
  color: #fff;
}

/* Adjust scroll padding when banner is visible */
html:has(.cookie-banner) {
  scroll-padding-bottom: 80px;
}
</style>

JavaScript: scroll focused element into view

// Ensure focused elements are not obscured by sticky elements
function ensureFocusVisible() {
  document.addEventListener('focusin', (e) => {
    const header = document.querySelector('.site-header');
    const footer = document.querySelector('.cookie-banner');
    const rect = e.target.getBoundingClientRect();
    const headerHeight = header?.getBoundingClientRect().height || 0;
    const footerHeight = footer?.getBoundingClientRect().height || 0;

    if (rect.top < headerHeight || rect.bottom > window.innerHeight - footerHeight) {
      e.target.scrollIntoView({ block: 'center', behavior: 'smooth' });
    }
  });
}
ensureFocusVisible();

Common mistakes

• Sticky headers that cover focused elements when users tab through the page.
• Cookie consent banners fixed to the bottom of the viewport that obscure footer links and form fields.
• Chat widget bubbles that overlap with interactive elements in the lower-right corner.
• Notification banners that slide in and cover the currently focused element.
• Not accounting for sticky elements when using scrollIntoView or anchor links.
• Modeless overlays that partially cover the page without trapping focus.