2.4.11 Focus Not Obscured (Minimum)
- Level AA
- Operable
- New in WCAG 2.2
Summary
Sighted keyboard users navigate by watching the focus indicator move from control to control. If the focused element sits behind a sticky header, a fixed footer, a cookie consent banner, or a chat widget, that thread is cut: the user presses Tab, nothing visible changes, and they have no idea where they are on the page. This criterion requires that when a component receives keyboard focus, it is not entirely hidden by content the author placed on top of it.
The requirement is new in WCAG 2.2 at Level AA, and the operative word is entirely. A focused button half covered by a sticky footer still passes here, because some part of it remains visible. The Level AAA sibling, 2.4.12 Focus Not Obscured (Enhanced), removes that allowance and requires no part of the focused component to be hidden. At AA, you are checking for total disappearance, and the usual culprits are fixed-position UI layered over scrolling content.
Official wording
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
EN 301 549 mapping
This success criterion is new in WCAG 2.2. EN 301 549 V3.2.1, the harmonised European standard currently in force, references WCAG 2.1 and contains no clause for it. A revision aligned with WCAG 2.2 is in progress; until it is published and cited in the Official Journal of the EU, this criterion is not part of the harmonised standard.
Checked against EN 301 549 V3.2.1 (2021-03).
In practice
Web
Test by tabbing through each page with all sticky UI in its real state: cookie consent banner showing, sticky navbar and any bottom bar present, chat launcher loaded, non-modal overlays open. At every Tab press, confirm that at least part of the newly focused element is visible. The classic failure is a page whose browser default scroll behaviour brings the focused link to the very bottom edge of the viewport, exactly where a fixed footer or consent banner sits, so the link is focused but invisible.
The common remediation is CSS scroll-padding (or scroll-margin on the elements themselves) on the scroll container, sized to match the sticky bars, so the browser scrolls focused elements clear of them. It is a small, low-risk fix worth suggesting in every report that logs this failure.
Two nuances keep false fails out of your findings. First, content the user can reposition (a draggable widget, a movable panel) is judged only in its initial, author-set position; if the user drags it over the focus path themselves, that is not a failure. Second, content the user opened themselves, such as a dropdown or a non-modal dialog that happens to cover the focused trigger, does not fail if the user can dismiss it without moving focus (Escape being the usual mechanism). The criterion targets obscuring the user cannot reasonably resolve.
iOS
Enable Full Keyboard Access (Settings, Accessibility, Keyboards) and connect a hardware keyboard, then tab through each screen watching the focus ring. The question is the same as on the web: does the focused element stay at least partially visible when persistent app UI is layered above the scrolling content? Watch banners pinned to the top or bottom of the screen, floating action-style buttons, mini players, and any always-on overlay the app draws itself.
Keyboard avoidance adds a wrinkle. The on-screen keyboard is system UI, not author-created content, so a focused field sliding under the system keyboard is not a failure of this criterion (though it is a serious usability defect worth reporting separately). An accessory bar or toolbar the app draws above the keyboard, however, is author content: if the focus ring lands on a control fully hidden behind that bar, it fails. Screens that scroll correctly for the keyboard but not for the app's own pinned bars are the most common finding.
Android
Test with a hardware keyboard or d-pad, moving focus through each screen and confirming the highlighted element never disappears entirely behind persistent app chrome: sticky bottom navigation, floating buttons, banner ads the app renders, or snackbar-style overlays that persist rather than time out. As on iOS, the IME (the soft keyboard) is system UI rather than author-created content, but panels, sheets, and bars the app itself keeps on screen count.
The native remediation analogue to web scroll-padding is correct inset handling: adjustResize behaviour (or the modern WindowInsets APIs) so scrollable content resizes around persistent UI instead of sliding beneath it, plus padding on scroll containers equal to the height of any bottom bar. Apps that draw edge to edge and forget to apply insets to their scroll views are the ones where focus routinely vanishes under the bottom navigation.
Pass and fail examples
Passes:
- A focused link scrolls behind a sticky footer but its top half remains visible: partially obscured content passes at AA.
- A page sets
scroll-padding-bottomequal to the height of its cookie banner, so tabbing always brings the focused control clear of it. - A user drags a movable chat panel over a focused button: only the panel's initial position is judged, and it started elsewhere.
- A focused text field sits under the on-screen keyboard on a mobile device: the system keyboard is not author-created content.
Fails:
- Tabbing down a long page places keyboard focus on a link that sits fully behind a fixed cookie consent banner at the bottom of the viewport.
- A sticky site header completely covers the focused element when the user tabs backwards up the page.
- A persistent chat widget in the corner fully overlaps a focused form control on narrow viewports.
- An app's focus highlight lands on a list row entirely hidden behind the sticky bottom navigation because the scroll container has no bottom inset.
Not a fail under this criterion:
- A dropdown the user opened covers its focused trigger, but Escape closes it without moving focus: user-opened, dismissible content is allowed.
- A focused element that is off screen simply because the page has not scrolled it into view: nothing author-created is covering it, so it is not a 2.4.11 failure, though it usually signals a focus management defect worth reporting on other grounds.
- A focused button with a faint, hard-to-see indicator: that is an indicator quality problem, not an obscuring problem.
Commonly confused with
- Focus Visible, SC 2.4.7 Focus Visible. If there is no visible indicator at all, cite 2.4.7. This criterion assumes an indicator exists and asks a different question: is the focused component itself covered by other content?
- Non-text Contrast, SC 1.4.11 Non-text Contrast. An indicator that is visible but too low contrast to perceive is a contrast finding. Obscured means covered, not faint.
- Focus Not Obscured (Enhanced), SC 2.4.12. The Level AAA sibling forbids any part of the focused component being hidden. If an auditor fails a partially covered control in a Level AA audit, they are applying the AAA criterion.
- Focus Order, SC 2.4.3. Focus jumping to an illogical place is an order problem. 2.4.11 is only about whether the place focus lands can be seen.
How AUDITSU tests this
AUDITSU's audit walkthrough includes a keyboard pass for every screen you review, performed with sticky UI in its real state: consent banners visible, chat widgets loaded, bottom bars present. The walkthrough asks you to tab through the full focus order and confirm each focused element remains at least partially visible, recording a pass, fail, or not applicable result per screen with the evidence attached, so the finding lands in your report tied to the exact screen and control.
Because EN 301 549 V3.2.1 does not yet include this criterion, AUDITSU tracks it under WCAG 2.2 conformance. When your audit targets the European Accessibility Act, the walkthrough treats 2.4.11 as forward guidance until the revised harmonised standard adopts WCAG 2.2.
For the full guided workflow, see the audit platform.