2.4.11 Focus Not Obscured (Minimum)

Level: AA | Principle: Operable | Since: WCAG 2.2 | Automation: Manual


What This Means

When an element receives keyboard focus, it must not be entirely hidden behind other content such as sticky headers, fixed footers, cookie banners, or chat widgets. The user must be able to see the focused element — at minimum, some part of it must be visible. If the focused element is completely obscured, the keyboard user is effectively blind to their position on the page.

Who This Affects

  1. Keyboard-only users — cannot see where focus has landed when it's hidden behind overlapping content
  2. Low-vision users — already struggle to track focus; obscured elements make it impossible
  3. Screen magnification users — may only see a portion of the screen; obscured focus is completely invisible
  4. Switch device users — rely on visible focus to confirm their selection

Common Pitfalls

1. Sticky headers covering focused elements

/* Common problem: sticky header overlaps content below */
header {
  position: sticky;
  top: 0;
  z-index: 100;
  height: 64px;
}
/* When user tabs to a link just below the header,
   the focus ring is hidden behind it */

2. Cookie banners / consent dialogs blocking focus

<!-- Bad: fixed cookie banner at bottom covers focused elements -->
<div class="cookie-banner" style="position: fixed; bottom: 0; z-index: 9999;">
  <p>We use cookies...</p>
  <button>Accept</button>
</div>
<!-- Links at the bottom of the page are hidden behind this -->

3. Chat widgets overlapping content

A fixed-position chat bubble or support widget in the bottom-right corner can obscure focused elements underneath it.

4. Notification toasts covering interactive elements

Toast messages that appear over buttons or links block the focus indicator while the toast is visible.

How to Fix

Scroll padding for sticky headers

/* Reserve space so focused elements scroll clear of the header */
html {
  scroll-padding-top: 80px; /* header height + buffer */
}

header {
  position: sticky;
  top: 0;
  height: 64px;
}

Ensure cookie banners don't block focus

/* Option 1: reserve space at the bottom */
body {
  padding-bottom: 80px; /* height of cookie banner */
}

/* Option 2: use a non-overlapping banner */
.cookie-banner {
  position: relative; /* not fixed */
}

Manage focus when modals/overlays appear

// When a modal or overlay opens, move focus into it
// so the user isn't tabbing behind it
const modal = document.getElementById('cookie-modal');
modal.querySelector('button').focus();

Position chat widgets so they don't overlap content

/* Give content area bottom padding to clear the widget */
main {
  padding-bottom: 80px;
}

.chat-widget {
  position: fixed;
  bottom: 16px;
  right: 16px;
}

How to Test

  1. Press Tab through every interactive element on the page, watching for focus landing behind sticky headers, fixed footers, cookie banners, or chat widgets.
  2. Open any cookie consent banners or notification toasts, then Tab through elements near the bottom of the page to check if focus is hidden behind the overlay.
  3. Resize the browser to a narrow viewport and repeat the Tab test, as overlapping is more common at small widths.
  4. Check that when a modal or overlay opens, focus moves into it rather than staying behind it.
  5. Pass: Every focused element is at least partially visible and not completely hidden behind sticky headers, footers, banners, or overlays.
  6. Fail: Any focused element is entirely hidden behind a fixed-position element like a sticky header, cookie banner, or chat widget.

axe-core Rules

| Rule | What It Checks | |------|---------------| | — | No automated axe-core rule for this criterion. Detecting visual obscurement requires manual testing. |

Sources

  1. W3C WCAG 2.2 — Understanding 2.4.11
  2. WCAG 2.2 What's New