2.4.11 Focus Not Obscured (Minimum)

1. What is the goal of this criterion?

Keyboard navigation is as much a part of the web as checking your phone over lunch. But what happens when you tab through a website and suddenly can’t see where you are? The focus is there – it’s just hiding behind a cookie banner, a sticky header or a chat window.

The goal of WCAG Success Criterion 2.4.11 is clear: when an element receives keyboard focus, at least part of it must stay visible. No focused element may be completely covered by other content – otherwise people lose track of where they are.

2. What exactly does it require?

This is a Level AA requirement for keyboard focus visibility that was added in WCAG 2.2:

The basic rule: when a user interface component receives keyboard focus, it must not be entirely hidden by content you created as the author.

Partial obscuring is allowed: unlike the AAA version, Focus Not Obscured (Enhanced), a focused element may be partly covered – as long as some of it stays visible. That’s still not great: the more is hidden, the harder the focus is to spot.

Typical culprits:

• sticky headers and footers
• cookie banners and notification bars
• non-modal dialogs
• chat windows and pop-up help

What the notes in the normative text clarify:

• If users can move content themselves (such as a draggable toolbar), only its initial position is evaluated.
• Content the user opened may cover the focus – as long as the focused element can be revealed without moving focus, for example by closing that content with Esc.

A simple example: a cookie banner at the bottom of the screen that completely hides focused links as you tab fails this criterion. It’s fine if it is modal – focus stays inside the banner until it’s dismissed – or if it’s positioned so it never completely covers anything.

3. Why does it matter for accessibility?

Imagine tabbing through an online shop to reach the “Buy” button – but a chat window covers it completely. You can’t tell whether focus has arrived or whether the page has frozen.

Unobscured focus improves accessibility because it:

• helps people with motor disabilities who depend on the keyboard
• shows the current focus to people using switches or voice control with keyboard commands
• supports people with low vision who zoom in a lot – at high zoom, sticky elements quickly take up a large part of the screen
• helps people with attention or memory difficulties keep track of their position
• makes orientation easier for anyone who can’t use a mouse right now

And finally: it makes interaction predictable and reliable. A visible focus indicator is only useful if it isn’t sitting behind something else – which is why 2.4.11 complements Focus Visible.

4. How to meet the criterion

Good focus management decides whether a website is genuinely usable with a keyboard. Here are some proven tips:

Ground rules for visible focus:

• Use CSS scroll-padding so browsers don’t scroll focused elements behind fixed areas.
• Build modal dialogs properly – focus stays inside the dialog until it’s closed.
• Check every breakpoint of your responsive design for hidden focus.
• Give notification bars and banners an easy-to-reach close button that also works with Esc.

Technical implementation:

/* Keeps the sticky header from covering focused elements */
html {
  scroll-padding-top: 5rem;    /* at least the header height */
  scroll-padding-bottom: 4rem; /* if a banner is fixed at the bottom */
}

Do:

• use scroll-padding for sticky elements
• build banners and notices as proper modal dialogs, or place them so they don’t cover anything
• test with the keyboard only
• check different screen sizes and zoom levels

Don’t:

• leave cookie banners or notices floating over content indefinitely
• let focus disappear completely behind fixed elements
• skip testing at high zoom levels – fixed areas grow with the zoom

Testing: automated tools can rarely detect obscured focus reliably. Tab through the entire page – forwards, and backwards with Shift + Tab – at several screen widths and at 200% zoom. You’ll find more in the article Keyboard navigation and focus.

5. Why this criterion matters for businesses

2.4.11 is new in WCAG 2.2. EN 301 549, the standard behind the European Accessibility Act and its German implementation, the BFSG, currently references WCAG 2.1 Level AA – so 2.4.11 is not explicitly required (as of October 2026). It’s still strongly recommended: a focus indicator that is nicely styled but hidden behind a banner helps no one.

1. Reach more people

Keyboard navigation isn’t only important for people with disabilities. Many experienced users who want to work fast rely on the keyboard too. Clear focus handling makes your website more accessible to all of them.

2. Fewer drop-offs

People who lose track of focus give up. That’s especially critical in checkouts and forms – exactly where revenue is at stake.

3. Fewer support requests

“I don’t know where I am” or “The website isn’t responding” – feedback like this often comes from obscured focus. Getting it right saves effort in customer support.

This section is general information, not legal advice.

6. The success criterion in the W3C’s words

Success Criterion 2.4.11 Focus Not Obscured (Minimum) (Level AA)

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

Note 1: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this success criterion.

Note 2: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered visually hidden due to author-created content.

In short: a component with keyboard focus must never be completely hidden by the site’s own content; content the user moved or opened is treated separately.