What Is Focus Not Obscured and Why 90% of Sites Fail It

If your website has a sticky header or a cookie banner, there's a good chance keyboard users can't see which element they've tabbed to. That's a WCAG 2.2 failure - and it's one of the most common accessibility issues on the web.

What WCAG 2.4.11 requires

When a user interface component receives keyboard focus, the component must not be entirely hidden by author-created content. In plain English: if someone is tabbing through your page, the focused element can't be completely covered by your sticky nav, cookie banner, or chat widget.

Why it matters

Keyboard users (including screen reader users, people with motor disabilities, and power users) navigate by pressing Tab to move between interactive elements. If a sticky header covers the focused element, the user has no idea where they are on the page.

How Lumi detects it

Lumi is one of the only tools that tests for this automatically. During keyboard tests, we simulate tabbing through the page and check whether each focused element is fully hidden behind any fixed or sticky positioned content.

We use `elementFromPoint` at five sample points on the focused element - if all five are covered by a fixed/sticky element, it's flagged as obscured.

How to fix it

The simplest fix is `scroll-padding-top` on your HTML element, set to the height of your sticky header:

html {
  scroll-padding-top: 80px; /* height of sticky nav */
}

This ensures that when the browser scrolls an element into view (including on focus), it accounts for the sticky header.