Focus not obscured

Silktide tests that when a control is selected with the keyboard, it is not completely hidden behind other content such as a cookie banner or a sticky header. A keyboard user who cannot see the selected control has no way of knowing where they are on the page.

The most common causes are elements that stay fixed in place while the page scrolls:

Banners at the top or bottom of the page, such as cookie notices
Sticky navigation bars and footers
Popup dialogs that allow focus to move behind them

This check covers total obscuring, as required at Level AA (criterion 2.4.11). The stricter companion, Focus not partly obscured, also flags controls that are only partly covered.

Why this matters

People who navigate by keyboard follow the indicator to know which control they are on. When focus moves to a control buried under a cookie banner or sticky footer, the indicator vanishes: the user cannot tell what pressing Enter will do, or even where they are, and may abandon the page entirely.

How to fix it

Prefer content that scrolls with the page over elements fixed on top of it.
Where a fixed banner or header must stay, use the CSS scroll-padding or scroll-margin properties so focused elements scroll clear of it - see WCAG technique C43.
For dialogs and popups, trap focus inside them while they are open so nothing behind can be focused. Most dialog libraries and the native <dialog> element do this for you.

How Silktide tests this

Simulate a keyboard user tabbing through every focusable element, on both desktop and mobile views of the page.
Simulate the browser vertically scrolling each focused element to the centre of the screen (see the note on scrolling below).
Check whether any other element sits on top of the focused element. Overlapping elements with transparent or semi-transparent backgrounds are ignored, as the focus indicator remains visible through them.
Flag the control if it is completely covered by a solid element. Partial overlap is not flagged by this check - that is what Focus not partly obscured tests.

Why we simulate scrolling

How much a browser scrolls between Tab presses varies with the window size, so whether a sticky header covers a focused element can differ between screens only a few pixels apart in height. Testing at one exact window size would flag issues that nobody with a slightly different window could reproduce.

Instead, Silktide evaluates each element as if scrolled to the centre of the screen. This purposely generous approach flags problems that affect all screen sizes consistently, and avoids ones that only affect one exact window height. The W3C does not specify how this criterion should be tested.

Dialogs that open after the page loads

If a page contains a dialog that is closed by default, Silktide assumes that while it is open, focus cannot leave it - which is how a correctly built dialog behaves. A faulty dialog that lets focus escape behind it may therefore not be flagged unless it is open when the page loads.

Troubleshooting

I can see the focused element fine

Check on a smaller window: elements obscured by sticky headers or footers often only collide at certain window heights. If you conclude the element is never meaningfully obscured, you can ignore the finding.