WCAG 2.4.11 is a Level AA rule, new in WCAG 2.2, that says when an item gets keyboard focus it must not be completely covered by something the site itself put on the page, such as a sticky header, a cookie banner or a floating chat button. Part of the item may be hidden and the page still passes; the whole item may not.
The problem it solves is simple. A keyboard user presses Tab, focus moves to a link, and the browser scrolls that link to the top edge of the window, straight under a fixed menu bar. The user now has no idea where they are. Below you will find a quick way to test for this and the one line of CSS that fixes most cases.
Quick facts
Level
AA (part of the set most laws and contracts ask for)Added in
WCAG 2.2Rule in short
The focused item is never 100 percent hidden by author contentUsual culprits
Sticky headers and footers, cookie banners, chat launchers, promo barsFast test
Tab and Shift+Tab through the page and watch every stopWho benefits
Keyboard users, switch users, people who zoom the page
What WCAG 2.4.11 asks for, in plain words
When an interface component (a link, button, form field or custom widget) receives keyboard focus, at least some of it must remain visible. If the only thing in the way is content the author added, like a fixed toolbar, the item cannot be fully hidden behind it.
Three details matter when you judge a result:
- Partly covered passes. If half of a button peeks out under a banner, the minimum rule is met. The stricter AAA version, numbered 2.4.12, asks that no part be hidden.
- Author content only. The rule is about layers your site creates. Browser toolbars or an on screen keyboard from the operating system are outside it.
- User opened layers get some room. The W3C explanation notes that if the person opened the covering content, such as a dropdown menu, and can close it without moving focus (for example with Escape), that does not count as a failure.
The official wording and examples are in the W3C Understanding page for Focus Not Obscured (Minimum).
How to test for obscured focus
- Load the page in a desktop browser and close nothing yet. Leave the cookie notice and any promo strip in place, because real first time visitors see them.
- Press Tab slowly and watch each focus stop. Pay attention when the page scrolls: that is the moment an item can land under a fixed bar.
- Go to the footer and press Shift+Tab back up. Browsers scroll the focused item to the top edge when moving up, which is where sticky headers live.
- Dismiss the banner, then test again with it gone, so you know which layer caused each problem.
- Zoom to 200 percent and narrow the window to phone width, then repeat the backward pass.
- For any stop you could not see at all, note the element, the layer covering it and the viewport size. Those three facts make the bug report easy to act on.
Automated checkers cannot judge this rule well, since it depends on scroll position and layering at the moment of focus. Treat it as a manual check in every accessibility test.
CSS example: stop the header covering focus
Most failures come from one fixed header. Scroll padding tells the browser to leave room at the edge when it scrolls something into view, so the focused item lands below the bar.
Fails: the header is fixed and nothing reserves space for it.
header { position: sticky; top: 0; height: 72px; }Passes: the page keeps a gap the size of the header, plus a little extra.
html { scroll-padding-top: 88px; scroll-padding-bottom: 64px; }
header { position: sticky; top: 0; height: 72px; }If the header height changes at different breakpoints, set the padding in the same media queries. For a single element that needs extra room, scroll-margin-top on that element does the same job locally.
Design choices that prevent the problem
Fixing this late is fiddly. Deciding it early in design is cheap.
- Keep sticky bars short. A slim header that hides on scroll down and returns on scroll up covers less.
- Turn off stickiness when the viewport is short, for example in landscape on a phone or at high zoom.
- Put consent notices in the page flow at the top rather than floating over the bottom edge.
- Give floating buttons a clear zone so links and fields never sit beneath them.
- Add a focus pass to your design review: tab through the prototype and look at the edges of the screen.
Questions people ask
What level is WCAG 2.4.11?
It is Level AA. So if your target is WCAG 2.2 AA, which is common in contracts and UK public sector rules, you need to meet it. It does not apply if your target is WCAG 2.1 AA, since it did not exist in that version.
Does 2.4.11 WCAG fail if focus is half hidden?
No. The minimum rule only fails when the focused item is entirely hidden by author content. Half visible passes 2.4.11, but it would fail the AAA rule 2.4.12, which wants the whole item uncovered.
Does a cookie banner fail this rule?
It can. If focus moves to a footer link that sits completely under the banner, that is a failure. Making the banner part of the page flow, or adding bottom scroll padding, usually fixes it.
Is a modal dialog a problem for focus not obscured?
A proper modal keeps focus inside itself, so items behind it never receive focus and the rule is not triggered. Problems appear with non modal panels that stay open while focus moves on to content underneath.
Can an automated checker find 2.4.11 issues?
Not reliably. The result depends on scroll position, screen size and which layers are showing at that moment. A short manual keyboard pass, forward and backward, is the dependable test.