WCAG 2.2 · Level AA · Operable
2.4.11 Focus Not Obscured (Minimum)
When a component receives keyboard focus, author-created content must not hide it entirely. Partial visibility can meet this minimum criterion; the enhanced criterion 2.4.12 has a stricter requirement.
Manual verification
How to validate 2.4.11 by hand
Check that a focused component is not entirely hidden by author-created content when it receives keyboard focus.
Start with the extension result
Reopen the reported URL and reproduce the same state (for example, after expanding a menu or submitting a form). Use the result’s Highlight action when available, or its affected-element details and CSS selector, to find the reported content. Apply the checks below to that content and its context. If the element or state has changed, rescan and record that difference before deciding whether the finding still applies.
- Tab through controls while sticky headers, banners, cookie notices, and open overlays are present.
- Scroll so focus moves near the top, bottom, and edges of the viewport; inspect the focused component itself.
- Determine whether any part remains visible or whether author-created content fully covers it.
Evidence to record
Record the focused control, viewport/scroll position, covering content, and whether the control is entirely hidden.
Scope and exceptions
The minimum criterion permits partial obscuring; 2.4.12 is stricter. User-created content and some user-agent presentation are not treated the same as author-created overlays.
Record the review outcome
- Confirmed: the recorded evidence shows the requirement is not met in the tested page state, and no applicable exception explains it.
- Not reproduced: the reported issue is absent in the current state. Record the URL, state, and affected element you checked; this does not prove other pages or states conform.
- Needs more review: evidence is incomplete, the content requires human judgment, or an exception is uncertain. Record what remains to be checked instead of treating it as a pass.
Why it matters
A keyboard user can lose track of the active component when sticky headers, banners, dialogs, or other page content cover it. Keeping at least part of the focused component visible helps users see where they are.
Examples and distinctions
Sticky header
As focus moves down the page, a fixed header must not cover the focused component completely.
Cookie or help banner
A persistent banner at the bottom of the viewport must not completely obscure a component that receives keyboard focus.
User-opened content
W3C notes an exception where a user can reveal the focused component without advancing focus. Check the normative wording and guidance for the exact conditions.