When a Sticky Header Hides the Next Step: The WCAG Focus Test

By Jonathan Anthony Burkett

Reporting and original analysis | November 8, 2026

A page can keep its navigation beautifully fixed at the top of the screen while making the next link disappear underneath it. For someone moving through the page with a keyboard, that is more than an awkward visual effect. The page has asked the person to continue an interaction while hiding the place where the interaction now stands. A polished layout can therefore contain a very practical uncertainty: where will the next key press go?

W3C's explanation of WCAG 2.2 Success Criterion 2.4.11, Focus Not Obscured (Minimum), identifies a Level AA requirement: author-created content must not entirely hide a component when it receives keyboard focus. Its examples include sticky headers, footers and other overlapping content. The minimum permits partial visibility; the enhanced criterion addresses the stronger outcome of no obscuration. The practical testing approach below is original guidance for examining a page, rather than a claim that one test can establish complete accessibility or legal compliance.

Test a journey, not a still image

Start with an ordinary task that a visitor might attempt, such as reaching an article's related links or moving to a subscription control. Use the keyboard to move through the available controls and observe where the current point of interaction appears. The question is not whether the page looked orderly when it first loaded. It is whether the focused control remains findable as the page moves, menus open, and fixed elements occupy part of the viewport.

This is a different observation from checking that a focus indicator exists. A border around a link cannot help the visitor see it if the entire link is covered. In a test notebook, describe what actually happened: which control received focus, what covered it, and which page condition produced the overlap. A specific account gives a designer something to investigate. A general complaint that the keyboard experience feels confusing leaves more of the problem to be rediscovered.

A screenshot can help document an overlap, but it should accompany the sequence that led there. Someone opening the page at a different scroll position may not reproduce the same state. Record a short route through the interface rather than an enormous list of every key pressed. The useful detail is the smallest set of steps that makes the issue understandable and repeatable for the team responsible for the page.

Include the layers a visitor actually meets

A clean test session may miss the content that covers part of a real visit. A site can display a cookie notice, an announcement strip, a persistent player or another panel. Those layers deserve to be included in the examination when they are part of the page's ordinary behavior. This is not a claim that every panel is prohibited. It is a reminder to test the combination that a person encounters rather than inspecting each component in isolation.

Consider a hypothetical article page with a fixed header and a bottom notice. A control near the edge of the visible content might be exposed under one arrangement and covered under another. Changing the window size could alter the amount of usable space again. These are test scenarios, not findings about a named website. Their value is to make the reviewer consider the full layout at the moment of interaction, including the space occupied by persistent content.

The testing plan should also include a return journey. Moving backward through controls may reveal a different overlap from moving forward. A person correcting a choice or returning to a link should have a usable route too. When a particular state depends on content the user opened, examine the exact criterion and its notes before assigning a conformance result. An observed inconvenience and a formally classified failure are related judgments, but they require different levels of care.

A fix needs the same task to succeed

Once an issue is understood, a team can consider how the layout should behave. The right change depends on the interface: fixed content may need different spacing, a different placement or a different interaction. It would be careless to prescribe one universal code snippet without seeing the page. The useful requirement for the person evaluating the repair is simpler: repeat the original task and check whether the focused component now remains visible under the conditions that exposed the problem.

A repair should not be judged solely by whether an automated warning disappeared. Where the issue involved a particular sequence, run that sequence again and look at the result. Check nearby controls as well, since a change to page spacing can affect more than the original location. This is targeted verification, not an invitation to declare the entire site accessible after correcting one obstruction. Accurate reporting keeps the scope of the improvement clear.

Responsibility can also be shared sensibly. A writer who notices an overlap can document it without needing to diagnose the rendering code. A designer can explain the intended behavior. A developer can investigate how the current layout produces the covered state. The point of a useful report is to connect those contributions around a visitor's actual task, so that ownership of the solution does not disappear between roles.

Make visibility part of acceptance

The strongest time to ask these questions is before a new fixed panel becomes a permanent design feature. A review can include a short keyboard journey alongside the usual checks of text, appearance and responsive layout. The resulting evidence can be modest: the task, the conditions, what was observed and whether the focused controls remained visible. It should be clear enough for another reviewer to understand what was checked and what was outside its scope.

For readers who manage a small website, the lesson is approachable. Choose one important journey, move through it with the keyboard, and watch the places where content overlaps. Keep the W3C explanation nearby when interpreting the result, and seek qualified accessibility review for broader assessment. A sticky header earns its place when it helps people orient themselves while leaving their next step visible. That is a concrete design responsibility worth examining in motion.

Image note: Illustrative photograph for a website testing notebook; it does not depict an identified accessibility audit. Credit: Barbara Olsen / Pexels. Source photograph; Pexels license.

#upstormed #jonathananthonyburkett #jonathanburkett #WCAG22 #WebAccessibility