Focus Not Obscured (Minimum)
Tier 1 · The normative floor
Baseline compliance
What the normative text of WCAG 2.2 requires, and nothing more. Only a failure of this tier is a WCAG failure.
The bare minimum
When a component receives keyboard focus, it is not entirely hidden by content the author created.
Normative text
Verbatim from WCAG 2.2, W3C Recommendation 12 December 2024. Underlined terms are defined below.
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Not required by the normative text
Common claims that this criterion does not support. Don't log these as WCAG failures.
- Keeping the whole focused component visible. Partly covered passes at AA; no part hidden is 2.4.12 (AAA).
Definitions used (1)
Glossary definitions are normative. Their notes are informative.
- user interface component
-
a part of the content that is perceived by users as a single control for a distinct function
Informative notes (3)
Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.
User interface components include form elements and links as well as components generated by scripts.
What is meant by "component" or "user interface component" here is also sometimes called "user interface element".
Notes in the criterion Informative
WCAG 2.2 lists notes among its informative material, which "does not create requirements that impact a conformance claim." They help interpret the criterion but are not part of the floor.
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.
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.
Tier 2 · The gap
Usability & user impact
Where content can meet this criterion and still make things harder for people with disabilities. These are not failures of SC 2.4.11, so raise them as usability defects. Known failures, including failures of related criteria, are listed in Tier 1.
A focused field that is 90% hidden behind a sticky footer passes, but keyboard users can't see what they're typing into.
Tier 3 · The golden path
Recommended best practice
The pattern that meets the floor, closes the gap, and avoids audit disputes. A recommendation, not a requirement.
Use scroll-padding to match sticky headers and footers, and keep cookie banners and chat widgets from covering focused content.
W3C's Understanding document and techniques for SC 2.4.11 ↗ are informative: sufficient techniques show ways to pass, and documented failures show common ways to fail, but neither changes what the criterion requires.
How SC 2.4.11 maps to the WCAG 3 draft
From this site's reviewed map to the WCAG 3 editor's draft. It's an interpretation: W3C has not published a mapping.
No provision in the current draft covers focus being obscured.
From WCAG 2.2, section 5.1: “The main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.”