Focus Not Obscured: Sticky Header and Cookie Banner Fixes (WCAG 2.4.11)

What WCAG 2.4.11 Focus Not Obscured actually requires

The normative text is short: when a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content. The key word is "entirely": at Level AA, a partly covered component can pass. The W3C explains this allowance by the complexity of today's responsive designs, while noting that the more of a component is obscured, the less easy it is to see. Authors should therefore try to reduce how much and how often the focused item is partly obscured.

The ideal outcome, no overlap at all, is covered by a separate Level AAA criterion: Focus Not Obscured (Enhanced). Treat Level AA as a floor, not a goal.

The criterion evaluates the focused component, not the focus indicator. The indicator only counts if it sits inside the component, or if focus is shown by a change to the component itself. The W3C says this gives a clearer metric, but a fully obscured focus indicator would likely fail 2.4.7 Focus Visible.

• Note 1: where users can reposition content in a configurable interface, only the initial position of that movable content is considered.
• Note 2: content opened by the user may obscure the focused component; if the user can reveal it without advancing keyboard focus, the focused component is not considered hidden by author-created content.

Focus not obscured: why a sticky header or cookie banner can hide focus

The W3C names sticky footers, sticky headers and non-modal dialogs as typical types of content that can overlap focused items: as a user tabs through the page, these layers can obscure the item receiving focus, along with its focus indicator.

The W3C explicitly names cookie banners as an example. A notification implemented as sticky content, such as a cookie banner, fails this criterion if it entirely obscures a component receiving focus. For sighted people who rely on a keyboard, or on a device that operates through the keyboard interface such as a switch or voice input, knowing where focus is matters a great deal: without seeing it, they may not know how to proceed, or may even think the system has become unresponsive.

Semi-transparent, blurred or dimming overlays deserve attention too. Because these overlays may not entirely obscure the focused item, it can pass 2.4.11, but it may separately fail 1.4.11 Non-text Contrast: the focus indicator must be evaluated against the contrast requirements of 1.4.11 as it appears under the overlay.

Fixing it with scroll-padding (CSS technique C43)

The sufficient technique the W3C lists for this criterion is C43: using CSS scroll-padding to un-obscure content. The W3C example: on a page with a sticky footer, the focused item is not completely obscured because content in the viewport scrolls up to always display the item with keyboard focus, using scroll padding. The W3C also mentions scroll padding for banners, so the banner does not overlap other content.

The snippet below is our own illustration, to adapt: the W3C Understanding page cites technique C43 without detailing its syntax. We set scroll-padding to a value matching the height of each sticky bar; check the result with the keyboard at every breakpoint.

/* Illustration: reserve room for the sticky header and footer */
html {
  scroll-padding-top: 5rem;    /* sticky header height */
  scroll-padding-bottom: 4rem; /* sticky footer height */
}

.site-header {
  position: sticky;
  top: 0;
}

/* Keyboard-visible focus indicator (technique C45) */
a:focus-visible,
button:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 2px;
}

Cookie banners and notifications: other ways to pass

Scroll-padding is not the only route. For a cookie banner or sticky notification, the W3C describes several ways of passing:

• Make the banner modal, so the user has to dismiss it before navigating the page. A properly constructed modal dialog always passes this criterion, because it takes focus on appearance and prevents interaction outside it until it is dismissed.
• Use scroll padding so the banner does not overlap other content.
• For a notification that does not require user action, close it on loss of focus.

Persistent content opened by the user

For persistent content the user opens themselves, such as an accordion, a chatbot or expandable side navigation, the W3C describes approaches that avoid obscuring focus:

• The new content displaces existing content, like an accordion pushing the rest of the page down.
• Existing content reflows to make room, like a sidebar that narrows the main content area.
• The opened content takes focus and keyboard navigation stays within it until it is dismissed; the W3C says to use this cautiously, as it can create an inequitable experience between keyboard and pointer users.
• The content opens into an area of the page containing no other content, provided you check that nothing is obscured at each responsive breakpoint.
• The content is hidden automatically when focus leaves it, or via a dedicated keyboard command such as Escape.

How it relates to Focus Visible (2.4.7)

Success Criterion 2.4.7 Focus Visible, also Level AA, requires that any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. Its purpose is to help people know which element has keyboard focus. The W3C adds that the indicator must not be time limited: once shown, it must remain visible.

The two criteria work together. 2.4.7 checks that the focus indicator is visible in at least one mode of operation; 2.4.11 checks that the focused component is not entirely hidden by author-created content. A perfectly styled focus ring is useless if it vanishes under a sticky header. Sufficient techniques for 2.4.7 include C15 (using CSS to change a component's presentation on focus), C40 (a two-color indicator for sufficient contrast) and C45 (using :focus-visible). Among its failures, F78 covers outline or border styles that remove or render the focus indicator non-visible, and F55 covers script that removes focus when it is received.

Testing focus not obscured on your site

A manual keyboard test lets you check this criterion. Go through each page template using only the keyboard, with Tab and Shift+Tab, watching at each step whether the focused element stays visible.

• Test with the sticky header displayed and with the cookie banner still open.
• Go through the whole page, down with Tab and back up with Shift+Tab, to check both the sticky footer and the sticky header.
• Repeat at every responsive breakpoint.
• Open persistent content (chat, feedback panel, side navigation), then check that Escape or keyboard scrolling reveals the focused element.
• Also check that the focus indicator is visible and has sufficient contrast.

Frequently asked questions

Further reading on Conformly

• Fix focus visibility in HTML
• French RGAA criterion 10.7 guide
• Overview of the RGAA 5 standard

Sources

This article relies on the official sources listed at the end of the page.

• W3C — Comprendre 2.4.11
• W3C — Comprendre 2.4.7