Your focus ring is fine. Your sticky header ate it.

Understanding WCAG 2.4.11 Focus Not Obscured (Minimum)

What is it?

WCAG 2.4.11 Focus Not Obscured (Minimum) is a Level AA criterion, new in WCAG 2.2.

When something receives keyboard focus, author-created content can’t entirely hide it. Sticky headers, sticky footers, cookie banners, and chat widgets are the usual offenders.

The criterion itself is one sentence:

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

“Author-created” is doing real work in that sentence. Content the browser puts on screen, like the find bar or an autofill dropdown, isn’t yours and doesn’t count against you. Everything you put on the page does count, including the parts you pasted in from somewhere else.

Why it matters

Keyboard users track their place on a page by watching the focus indicator. When it disappears under a sticky header, they’re still moving. They just can’t see where they are.

So they press Tab again. And again. Now they’ve skipped past the thing they were looking for and lost their place entirely.

Who it affects

People:

One word does a lot of work

The criterion says entirely hidden. At Level AA, partly covered still passes.

That’s deliberate, and it keeps the bar more reachable. But technically visible and actually usable aren’t the same thing. If all someone can see is a sliver of the outline, you’ve met the letter and missed the point.

If you want the stricter version, it exists as a Level AAA criterion. See How this differs from 2.4.7 below.

Common failures

  1. The sticky header swallows the focused link. You Shift+Tab back up a long page. The browser scrolls the link into the viewport, but it’s underneath the sticky header.
  2. A sticky footer action bar covers the last field. The action bar covers up the last field in a form, making it hard to see when the field has focus. It’s also hard or impossible to complete a field that’s hidden or partly hidden.
  3. The cookie banner parks over your content. It loads on top of the page, so the first few things you Tab to land behind it.
  4. The chat bubble sits on something focusable. A floating help widget in the corner, permanently covering whatever’s underneath it.
  5. The skip link drops you behind the header. Focus lands on the main heading, scrolled to the top of the viewport, right under the sticky header.

Solution

Reserve the space the sticky thing occupies

Browsers already scroll focused elements into view. The trouble is they scroll them right to the edge of the viewport, which is where sticky headers and footers live. Tell the browser to stop short.

Scroll padding on the scroll container

One property, and every scroll-into-view stops below the header instead of under it. Match the values to your real header and footer heights.

html {
  scroll-padding-top: 6rem;
  scroll-padding-bottom: 4rem;
}

Or add scroll-margin on the targets

When only some elements need the offset, put it on those elements directly instead of on the whole document.

:target,
.section-heading {
  scroll-margin-top: 6rem;
}

Which of the two?

Reach for scroll-padding first. It goes on the scroll container, usually html, and it applies to everything inside, which is why a single declaration covers most of a site.

Use scroll-margin when the offset belongs to particular elements rather than the whole page, or when one target needs to clear more room than your site-wide value gives it. The two combine, so you can set a global scroll-padding and still bump an individual element with scroll-margin on top of it.

Let the header get out of the way

Scroll padding only helps when the browser scrolls. If the focused element is already on screen and under the header, nothing moves.

For that case, shrink the header on scroll, hide it while the user is tabbing, or drop the sticky behavior on short viewports.

That gap is worth understanding, because it catches people who added scroll padding and assumed they were finished. When focus moves, the browser only scrolls if it decides the element isn’t visible, and that decision is about whether the element sits inside the scrollport. It doesn’t check whether something is sitting on top of it. An element tucked under a sticky header is, as far as the browser is concerned, already on screen. So no scroll happens, and scroll padding never gets a chance to apply.

Check the things you didn’t build

Cookie banners, chat widgets, and notification bars usually arrive as a script someone pasted in. As far as WCAG is concerned, they’re still author-created content.

Make banners dismissible by keyboard, and check what that floating widget is sitting on top of.

What doesn’t fail this one

The last two come straight from the criterion’s own notes, and the wording matters.

Note 2 covers content the user opened, and it’s specific about the escape route: the exception applies only if the user can reveal the focused component without advancing the keyboard focus. Pressing Tab advances focus, so “you can always just Tab past it” is the one route that doesn’t qualify. Esc does qualify, because it reveals what’s behind without moving focus anywhere.

Note 1 covers content the user repositioned, and says only the initial positions of user-movable content count for testing.

How this differs from 2.4.7

2.4.7 Focus Visible asks whether there’s a focus indicator at all. This one asks whether anyone can see it.

You can pass 2.4.7 with a gorgeous focus ring and still fail 2.4.11, because a sticky header is hiding it.

Level AAA goes further: 2.4.12 allows no part of the focused component to be covered.

There’s a fourth criterion in this family worth knowing. Together they answer four different questions:

One precision note if you’re citing these in an audit. 2.4.11 and 2.4.12 are written about the focused component, not about the focus ring drawn around it. In practice the two travel together, since an indicator hugs the thing it’s indicating. 2.4.13 is the one that’s actually about the indicator.

How to test

Test both directions, because each one walks into a different sticky element. Tabbing forward brings the next element in from the bottom of the viewport, which is where a sticky footer sits. Shift+Tab brings it in at the top, where the header sits. Going backward is the step people skip, and it’s where this usually shows up.

Automated checks struggle here. It depends on scroll position, stacking order, and viewport height at the moment focus lands.

Closing

A focus indicator nobody can see has the same result as no focus indicator at all.

The good news: this is usually an easy fix, and one property covers most of a site.

Tab through your longest page and watch the top of the screen.

Learn more

Read the full breakdown: a20y.com/wcag-plain-english/2-4-11-focus-not-obscured-minimum

Want more clear and actionable WCAG breakdowns? Check out wcagInPlainEnglish.com