Why Keyboard Focus Must Not Be Obscured

Focus Not Obscured ensures that when users navigate with a keyboard, the item that receives focus remains visible on screen.

If a user moves focus to a control but cannot see it because it is completely covered by other content, they lose their point of interaction and may believe the page is unresponsive.

A Quick Primer

Keyboard focus
Keyboard focus is the currently active element on a page: the link, button, or input that will respond if the user presses Enter or Space. A visible outline or highlight usually indicates it.

Viewport
The viewport is the visible portion of the page on screen. When users zoom in or use screen magnification, the viewport becomes much smaller.

Author-created content
This includes any content layered, fixed, or positioned by the website itself, such as sticky headers, cookie banners, chat widgets, or overlays. Browser UI (address bar, dev tools) does not count.

Modal dialog
A modal dialog is a container that takes keyboard focus when it appears and prevents interaction with the rest of the page until it is dismissed.

WCAG 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.

Notes

• Only the initial position of user-movable content is evaluated.
• Content opened by the user may obscure focused elements if the user can reveal the focused item without moving focus.

Why This Matters

For sighted users who rely on a keyboard, focus is the only indicator of where interaction will occur next.

If the focused element is completely hidden:

• Users may not know how to continue
• Users may repeat keystrokes unnecessarily
• Users may abandon the task, assuming the interface is unresponsive

This issue is especially severe at high zoom levels, where only a small portion of the page is visible at any time.

Who This Helps

This criterion primarily supports:

• Keyboard-only users
• Screen magnifier users
• Users of speech input or switch devices
• Users with attention or short-term memory limitations
• Users navigating complex or responsive layouts

What “Not Obscured” Means

This criterion evaluates the focused component itself, not just the focus indicator.

A component fails if it is:

• Completely covered by author-created content
• Impossible to see without moving the focus elsewhere

A component passes if:

• At least part of it is visible in the viewport, so the user can locate it, or
• The user can reveal it (for example, by scrolling or dismissing an overlay) without changing focus

Partial obscuring is allowed at Level AA.
Complete visibility is encouraged, but required only at Level AAA.

Intent of the Criterion

This success criterion intends to ensure that users can always locate the active point of keyboard interaction.

Modern interfaces often include overlapping elements such as:

• Sticky headers or footers
• Cookie banners
• Chat widgets
• Slide-in panels

This criterion does not forbid overlapping content.
It requires that overlapping content never fully hides the focused element.

Why This Happens Technically

This problem exists because browsers do not automatically account for overlays when managing focus.

Common causes include:

• position: fixed and position: sticky remove elements from normal document flow
• Default browser focus scrolling does not “know” about headers or footers
• Focus movement and visual scrolling are handled separately
• scrollIntoView() behaviour varies between browsers

Because of this, authors must explicitly account for overlapping UI.

Example fix using scroll padding:

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

This ensures focused elements scroll into view without being hidden behind fixed UI.

Common Causes of Focus Obscuring

Focus is commonly obscured when:

• Sticky headers or footers overlap content without scroll padding
• Persistent notifications cover form fields or links
• Non-modal dialogs remain open while focus moves behind them
• Chat widgets overlay content without repositioning
• Overlays appear without taking focus or dismissing on blur

User-Opened vs Author-Created Content

User-opened content (conditionally allowed)

Content intentionally opened by the user may obscure other elements if:

• It can be dismissed (for example, with Escape)
• The user can scroll to reveal the focused item
• Focus does not need to move to resolve the obstruction

Examples include:

• Dropdown menus
• Date pickers
• Tooltips
• Combobox lists

Author-created persistent content (higher risk)

Content that appears automatically or persists independently of focus is more likely to fail:

• Sticky cookie banners
• Fixed chat windows
• Floating feedback panels
• Persistent non-modal dialogs

If these fully cover the focused component, the criterion fails.

Modal Dialogs (Special Case)

A properly implemented modal dialog generally passes this criterion because:

• The dialog takes focus when it appears
• Focus is constrained within the dialog
• The focused element inside the dialog remains visible

Failures occur when:

• Dialog-like overlays do not take focus
• Focus can escape behind the overlay
• Internal dialog content scrolls and clips focused controls

Relationship to Other Criteria

Focus Not Obscured interacts closely with:

• 2.4.7 Focus Visible — focus indicators must be visible
• 1.4.11 Non-text Contrast — focus indicators must remain perceivable under overlays
• 2.1.2 No Keyboard Trap — focus must not be trapped behind layers

This criterion evaluates visibility, not contrast or focus order—but failures often cascade.

Examples

Passing example

A page includes a sticky footer.
As users tab through content, the page scrolls so the focused element remains partially visible above the footer.

Passing example

A cookie consent dialog appears and takes keyboard focus.
Users cannot interact with the page until it is dismissed, and focus remains visible throughout.

Failing example

A fixed-position chat widget expands and fully covers a focused form field.
Focus moves behind the widget and cannot be revealed without moving focus elsewhere.

Rule Description

When a component receives keyboard focus, it must not be completely hidden by author-created content. If content overlaps the focused component, users must be able to reveal it without advancing focus.

The Algorithm

1. Navigate the page using only the keyboard
2. Move focus to each interactive component
3. Check whether the focused component is visible
4. If it is fully hidden:
   • Try scrolling or dismissing overlays without moving focus
5. If the focused item cannot be revealed:
   • The criterion fails

How to Avoid Focus Obscuring

• Use scroll-padding or scroll-margin with sticky UI
• Ensure persistent overlays do not cover focusable content
• Make dialogs modal or dismissible with Escape
• Reflow content instead of layering it
• Test at high zoom and small viewport sizes

How to Test This

• Navigate using Tab and Shift+Tab only
• Test with sticky headers, footers, and widgets enabled
• Zoom the page to 200% or more
• Confirm focused elements are always at least partially visible
• Verify overlays can be dismissed or scrolled away without moving focus

Wrapping Up

Focus Not Obscured (Minimum) is about maintaining a visible point of interaction. Overlapping content is allowed. Invisible focus is not. This criterion ensures keyboard users can always see where they are and what they are interacting with, even in complex, modern layouts.