Focus Not Obscured: Measuring 2.4.11 Instead of Guessing

WCAG 2.2 became a W3C Recommendation on October 5, 2023, and it added nine new success criteria on top of 2.1. Criterion 2.4.11, Focus Not Obscured (Minimum), sits at Level AA, the level regulators, courts, and contracts almost always reference. It says that when a component receives keyboard focus, it must not be entirely hidden by author-created content.

Entirely is the operative word. Partially covered passes at AA. A sticky header overlapping ten percent of a focused button is a pass at this level, and a fail at Level AAA under 2.4.12, which allows no part of the focused component to be covered. The AA rule is deliberately lenient, and sites still fail it constantly, because nobody tests it.

What the criterion actually asks

Sticky headers are the most common cause. A page with a 72 pixel sticky header and no scroll margin will hide the focused link behind the header every time a keyboard user tabs to it. Cookie banners are the second: the W3C guidance on 2.4.11 uses a cookie banner hiding the focused control as its example of a failure. Chat widgets and newsletter bars do the same.

The pattern is always identical: an element that sticks to the viewport, and a focus move that scrolls the page without accounting for it. The page scrolls the focused element to the top of the viewport, and the sticky element is already sitting at the top of the viewport. The focused control ends up underneath it, invisible, and the keyboard user has no idea where they are.

The usual suspects

The cheapest fix is a CSS property, not a redesign. Add scroll-margin-top to focused elements, sized a little larger than the sticky header: a 72 pixel header gets a 90 pixel scroll margin, so a focused link always sits visibly below it. One rule, applied to the elements that take focus, and the failure disappears.

The alternative is to change how the page scrolls on focus, but scroll-margin is the fix the W3C guidance points to, and it is the one that survives a redesign. A header height change means updating one number. A scroll handler means debugging a script every time the layout changes.

The fix is scroll-margin, not a redesign

Tab through the page with every sticky element in place, and watch each focused control as it receives focus. Count the ones that disappear entirely behind a header, banner, or widget. Each one is a failure of 2.4.11, and the count is the metric: failures per page, and pages with any failure.

Keep reading: Heading order pass rate: the metric that finds skipped levels, Form label coverage: counting inputs with no accessible name.

How to score it in your audit

Report it as a rate, not a feeling. 'Three of forty focusable elements are fully obscured on the checkout page' is an audit finding. 'The focus experience feels off' is not. Automated checkers catch only a fraction of WCAG 2.2 criteria, and this one needs a keyboard and a pair of eyes. Budget the time for it, because the scan will not do it for you.

Frequently asked questions

What does WCAG 2.4.11 require?

When a component receives keyboard focus, it must not be entirely hidden by author-created content like a sticky header, banner, or chat widget. Partially covered passes at Level AA. Fully hidden fails.

What is the difference between 2.4.11 and 2.4.12?

2.4.11 is Level AA and allows partial overlap: only fully hidden fails. 2.4.12 is Level AAA and stricter: no part of the focused component may be covered, so even a ten percent overlap fails.

How do I fix a focused element hidden behind a sticky header?

Add scroll-margin-top to focused elements, sized a little larger than the header. A 72 pixel header gets a 90 pixel scroll margin, so a focused link always sits visibly below it.

Can automated tools test focus not obscured?

Not reliably. The criterion needs a keyboard tab-through with sticky elements in place, watching each focused control. Automated checkers catch only a fraction of WCAG 2.2 criteria, and this one needs a person.