Focus Not Obscured (Enhanced)
When a component takes keyboard focus, no part of it may sit under anything you added to the page. The Level AA version allows the component to be partly covered. This one allows none of it. The gap between the two levels is bigger than partial against total, because the AA version also forgives two things this one does not. Content the reader moved themselves is judged only where it started, and content the reader opened does not count as obscuring. Neither allowance exists here.
Why it matters
A component half under a sticky bar leaves the reader guessing what has focus, and W3C puts the consequence more bluntly than we would. They may think the system has stopped responding. Magnification makes it worse in a way that is easy to miss. Zooming shrinks the usable viewport while the sticky header keeps its height, so the same bar swallows a far larger share of what the reader can see.
Who this rule protects
Sighted keyboard users are the main group, and that includes people using speech input, sip-and-puff switches, on-screen keyboards and scanning software. People with low vision using magnification, and people with attention or short-term memory limitations, are the other two W3C names.
How to check it yourself
- Tab down a long page that has a sticky header and watch where focus lands.
- Do the same with a sticky footer, which is the case W3C leads with.
- Check any dimming or blurring overlay, because partial visibility through one still fails.
- Repeat with the cookie bar present, and with the page magnified, where a fixed-height bar covers proportionally much more.
Failures we see most often
- A sticky footer covers the bottom of the control that just took focus.
- A modal's dimming scrim sits over the focused component, which fails even though the component is still faintly visible.
- A non-modal dialog or a promotional panel opens over the control the reader has just tabbed to.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Low visionpeople who can see the screen but not easily
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Voice controlpeople who operate the page by speaking to it
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How to fix it
- Set scroll-padding on the scrolling container to match the height of your sticky bars, which is the technique W3C names and which you write once.
- Make a cookie banner modal, so it has to be dealt with before the reader tabs into the page behind it.
- Have a notification that needs no action close itself when it loses focus.
Step-by-step fix guides (1)
Passes vs. fails
Passes
The same field scrolls clear of the header, fully visible, because the scroller carries matching scroll padding.
Fails
Tabbing to a form field scrolls it half under a 90px sticky header.
In audits and lawsuits
This one is new in WCAG 2.2, at AAA, alongside the Level AA version at criterion 2.4.11. Two things surprise teams. Sticky footers are W3C's own leading example rather than sticky headers, and a semi-transparent or blurred overlay fails even though the component is still half visible through it. The named fix is CSS scroll-padding on the scrolling container, which you set once, rather than scroll-margin on every focusable element.