F110: When Sticky Headers Hide Keyboard Focus

The W3C failure document for F110 (opens in new window) describes exactly two scenarios. A sticky footer hides the focused element as a user tabs down. A sticky header hides it as they tab up. That's the whole thing — two scenarios, one clear failure. The simplicity is almost misleading, because the legal and human consequences of getting this wrong are anything but simple.

The Failure

WCAG 2.2 Success Criterion 2.4.11 Focus Not Obscured (Minimum) (opens in new window) requires that when a UI component receives keyboard focus, it is not entirely hidden by author-created content. F110 documents the specific failure pattern where sticky positioned elements — headers and footers that remain fixed as the viewport scrolls — completely cover the focused element.

The key word in the criterion is entirely. SC 2.4.11 is the minimum threshold: partial obscuring passes at this level (though SC 2.4.12 Focus Not Obscured (Enhanced) (opens in new window) tightens that to require no obscuring at all). F110 captures the most egregious version — total disappearance of the focus indicator behind a sticky element.

The failure pattern looks like this in practice:

<!-- Failure: Sticky footer tall enough to cover focused elements -->
<style>
  .sticky-footer {
    position: fixed;
    bottom: 0;
    width: 100%;
    height: 120px; /* tall enough to completely obscure focused links above it */
    background: #fff;
    z-index: 1000;
  }
</style>
<footer class="sticky-footer">
  <!-- cookie banner, chat widget, nav bar -->
</footer>
<!-- As user tabs through links, the focused element disappears behind the footer -->
<a href="/contact">Contact Us</a>

Same failure, inverted, for sticky headers:

<!-- Failure: Sticky header covering elements as user tabs upward -->
<style>
  .sticky-header {
    position: fixed;
    top: 0;
    width: 100%;
    height: 80px;
    background: #fff;
    z-index: 1000;
  }
</style>
<header class="sticky-header">!-- site nav --></header>

Why This Matters

Keyboard navigation is not a niche use case. People who rely on keyboards include users with motor disabilities who cannot use a mouse, users who prefer keyboard efficiency, and users of switch access devices. For all of them, the focus indicator is the cursor — it tells them where they are on the page and what they're about to activate.

When a sticky footer covers that indicator completely, the user loses their place. They don't know if focus moved. They don't know what they're about to activate. They may press Enter on a link they can't see. They may tab forward or backward trying to relocate themselves. The interaction breaks down entirely.

Cookie consent banners are a particularly common offender here. They're sticky, they're often tall, and they're frequently deployed by third-party scripts that development teams don't audit for accessibility. The irony: a banner designed to communicate user rights actively prevents a segment of users from exercising them.

This failure also exposes a gap that automated testing frequently misses. As our research on automated vs. manual testing documents, automated tools detect at most 37% of accessibility failures. F110 is exactly the kind of contextual, interaction-dependent failure that falls outside that detection window — a tool can flag position: fixed but cannot reliably determine whether the fixed element's height, at actual viewport sizes, will completely obscure a focused element during real tab navigation.

The Fix

The corrected pattern uses scroll-padding or scroll-margin to ensure the browser accounts for fixed elements when scrolling focused elements into view:

/* Fix: Account for sticky header height in scroll behavior */
html {
  scroll-padding-top: ; /* matches sticky header height */
}
/* Or per-element: */
a:focus, button:focus, input:focus {
  scroll-margin-top: ;
}

For sticky footers:

html {
  scroll-padding-bottom: ; /* matches sticky footer height */
}

This approach instructs the browser to offset scroll position so the focused element appears above (or below) the sticky element rather than behind it. It's a CSS-only fix, no JavaScript required, and it applies globally across all focusable elements.

Alternatively — and this is worth considering architecturally — evaluate whether the sticky element needs to be as tall as it is. Cookie banners that consume 120px of viewport real estate are a design choice, not a technical necessity. Reducing the height may resolve the failure without any scroll-padding logic.

Applying This

In code review: Any PR introducing position: fixed or position: sticky should trigger a checklist item: does this element's height, at minimum viewport sizes, risk completely covering focusable content? This is a design review question as much as a code review question.

In automated testing: Configure your test suite to flag position: fixed elements with significant height values as requiring manual review. Axe, Deque, and similar tools won't catch F110 automatically — this needs human judgment.

In manual testing: Tab through the entire page with the sticky element present. Do this at multiple viewport heights (768px is a useful minimum). Watch specifically for moments where focus appears to disappear. Browser DevTools' accessibility panel can help you track focus location even when it's visually hidden.

Quick win vs. systemic fix: Adding scroll-padding to the root element takes minutes and resolves the failure immediately. The longer-term work is auditing all third-party sticky components — chat widgets, cookie banners, floating CTAs — that teams often deploy without accessibility review. As our research on compliance frameworks notes, third-party components are a persistent gap in organizational accessibility programs because procurement and development workflows don't consistently include accessibility criteria.

CORS Perspective

From a risk and legal priority standpoint, F110 sits at an interesting intersection. WCAG 2.2 is newer than 2.1, and SC 2.4.11 has not yet accumulated the litigation history of older criteria. But the DOJ's updated Title II regulations (opens in new window) reference WCAG 2.1 AA as the technical standard for state and local governments — and the regulatory trajectory strongly suggests WCAG 2.2 adoption will follow. Organizations that treat 2.2 failures as optional now are building technical debt that will become legal exposure. F110 is also the kind of failure that shows up in manual audits requested during litigation discovery, precisely because automated scans miss it. The settlement trap is real: organizations that settle accessibility complaints without fixing systemic issues — like third-party sticky component governance — find themselves back in the same position within two to three years. Getting scroll-padding right is a five-minute fix. Building the process that catches the next sticky component before it ships is the actual work.