Skip to content
Pandus

WCAG 2.4.11 Focus Not Obscured (Minimum)

Updated October 14, 2026 · 3 min read

Level
AA · WCAG 2.2 (new in 2.2)
EN 301 549
9.2.4.11 Only in V4.1.1 (WCAG 2.2); the harmonised V3.2.1 does not contain it yet.
What the checker tests
Manual review: an automated tool cannot check this criterion reliably.
Official text
Understanding 2.4.11 Focus Not Obscured (Minimum) (W3C, in English)

Success criterion 2.4.11 is new in WCAG 2.2. It makes sure keyboard users can actually see the element they have moved to, instead of focus disappearing behind a sticky header, chat button or cookie banner. It is level AA and part of EN 301 549 (clause 9.2.4.11).

What the criterion requires

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

Key points from W3C:

  • at level AA, partly covered is acceptable — the element must not be entirely hidden. Level AAA (2.4.12 Focus Not Obscured (Enhanced)) asks that no part is hidden;
  • where the user can move content (for example drag a toolbar), only the initial position of that content is considered;
  • content opened by the user may cover the focused element; if the user can reveal it without moving keyboard focus (for example by pressing Esc to close a popup), it is not considered hidden.

Typical failures on an online shop

  • a sticky header or "Add to cart" bar that covers links and buttons as the user tabs down the page;
  • a cookie consent banner fixed to the bottom of the screen that hides the footer links and form fields behind it;
  • a floating chat or "Back to top" button sitting over checkout fields;
  • a promo bar that slides in and covers the focused element;
  • a non-modal "Newsletter" panel that stays open while focus moves behind it.

How to check it

Automated: there is no axe-core rule for this criterion. Whether focus is hidden depends on scroll position and overlapping layers at the moment of focus, which axe does not test, so it needs a manual check.

By hand: on a laptop-size window, and again at 200 % zoom, tab through the whole page with the cookie banner still open, then again after dismissing it. Watch the sticky header, sticky "Add to cart" bars and floating buttons. Every time focus lands on an element, at least part of it must be visible. Pay attention to the checkout form and the footer.

How to fix it

  • Add scroll-padding-top (and scroll-padding-bottom) to the scrolling container equal to the height of sticky bars, so focused elements scroll into a free area.
  • Make the cookie banner modal (focus moves into it and stays until a choice is made) or place it so it does not cover content.
  • Reduce the size of sticky elements on small screens and when zoomed.
  • Let users close floating widgets with Esc and from the keyboard.

Frequently asked questions

Does a sticky header fail WCAG 2.4.11?

Only if it covers a focused element completely. If part of the element stays visible, 2.4.11 (AA) is met; the AAA criterion 2.4.12 asks that no part is hidden. CSS scroll-padding usually fixes it.

A non-modal cookie banner that fully hides the element receiving focus fails. W3C describes ways to avoid that: make the banner modal so it takes focus, use scroll padding so focused elements stay clear of it, or close the banner when focus leaves it.

Is 2.4.11 new in WCAG 2.2?

Yes. Focus Not Obscured (Minimum) was added in WCAG 2.2 at level AA, together with Focus Not Obscured (Enhanced) at level AAA.