WCAG 2.4.12 — Focus Not Obscured (Enhanced)
The AAA version of focus-not-obscured: zero overlap. The focused component is fully visible, end of story. Sticky chrome and floating panels need real scroll-margin or they need to go.
What this requires
When a user interface component has keyboard focus, no part of the component is obscured by author-created content. Unlike 2.4.11, which allows partial overlap, the AAA criterion requires complete visibility.
How AI coding tools fail this
Same failure shapes as 2.4.11, with no tolerance for partial overlap. AI-generated sticky headers, footers, cookie banners, and chat widgets all fail at AAA unless paired with scroll-margin and focus-management code that keeps the focused element fully clear.
The unique AAA failure: a focused element clipped at a single edge because the scroll-margin was tuned to the chrome height but not to the focus-ring offset. The ring extends a few pixels beyond the element; the chrome cuts off the ring; the criterion fails even though the element itself is visible.
Edge cases
- AAA target. Most teams should target AA's 2.4.11 first.
- Focus-ring offset has to be accounted for in the scroll-margin calculation.
- Modals overlaying the page are fine because the modal contains the focus while it's open — the page content underneath isn't focused.
- Resize behaviour: at higher zoom levels, the chrome takes a larger fraction of the viewport. Test focus-not-obscured at 200% zoom.
- Hover-revealed components can obscure focus too; the criterion applies regardless of how the obscuring content was triggered.
How Jeikin handles this
Same runtime walk as 2.4.11. The dashboard maps each finding to both criteria when a project targets AAA, with stricter pass criteria for AAA (zero overlap).