ACCESSIBILITY ≠ OVERLAY · 38
Visible keyboard focus when a sticky header covers the next step
📅 11 November 2026 · ⏱ 6 min read
Pressing Tab can move focus to a control behind a sticky header. The page still responds, but the person navigating has lost the visual reference they need to continue.
01. Test a booking journey
Open a booking page and choose a date using the keyboard. When you press Tab, you expect to find a link explaining changes or a button to continue. The document scrolls a few pixels and the outline disappears. Focus has reached the correct control, but the header pinned to the top covers it. Pressing Enter could change the step before you have seen which action you are about to activate.
This is easy to miss during a mouse review. The pointer marks your chosen position and allows you to adjust scrolling before acting. With a keyboard, the browser advances focus according to the document’s sequence and determines when to scroll. Preserve that sequence during the test. Manually scrolling before looking can conceal the very failure you want to reproduce.
02. Separate focus, its indicator and its order
Focus identifies the element receiving keyboard input. The indicator is the visual cue that shows its location. Focus order determines which control comes next. An overlapping header can cover a button with a well-designed focus indicator. Conversely, a button can be in view and show no cue when focused. It is also possible to see a focused control clearly when it arrives at an unexpected point in the task.
To isolate the problem, note the control you expect and the one that receives focus. If you use browser developer tools, inspect the active element without changing page focus or repeat the sequence with the inspector ready. Compare the control’s rectangle with the overlapping layer. A screenshot shows the symptom. Keyboard steps and component state make it reproducible.
03. What WCAG 2.2 requires
Success criterion 2.4.7, at level AA, concerns the visibility of the focus indicator. Criterion 2.4.11, also AA, checks that a focused component is not completely hidden by content created by the site. Assess both independently. Seeing a sliver of the button may avoid complete obscuration while still making it difficult to understand what the button does.
Criterion 2.4.12, at level AAA, addresses partial obscuration. As a design aim, keep the whole control and its indicator visible. Criterion 2.4.3, at level A, concerns whether sequential focus preserves meaning and operability when the sequence affects them. A sticky header can lead to a failure of one requirement while the others are met. Describe the observed behaviour in the report and cite the criterion that matches it.
04. Find the layer taking up the reading area
A sticky header can change height on scroll, when the menu opens or when the window narrows. A notice at the bottom, an action bar or a help panel may occupy part of the same viewport. Each component may work well by itself while leaving little space when combined. What matters is its height in the state in which the failure occurs.
Check which container scrolls. On a simple page it is often the document. In an application it could be an inner panel with its own scroll position and toolbar. A setting on the document may never reach that panel. Temporarily disable the fixed position in the inspector and repeat the same keyboard sequence. If the control comes into view, you have a concrete explanation to test in the template.
05. Reserve room inside the scrolling container
One approach is to set scroll-padding-block-start on the scrolling container to account for the space occupied by the header. If there is a fixed bar at the bottom, consider scroll-padding-block-end. W3C technique C43 demonstrates combining scroll padding with actual layout space so the last item can come out from behind a bar. Check both ends of the journey, because scrolling has limits.
A fixed height copied from the desktop view may be too small when the menu wraps to a second line. Use values that reflect the template’s states and test resizing. If the layer takes up too much of a short viewport, letting it move with the content may be the best decision. Check automatic focus scrolling and in-page links, as both can position content close to a header.
06. Keep the focus cue visible in every state
Keep the browser’s own indicator or design one that stands out against the actual surfaces of the site. An outline that works on a white card can disappear against a dark blue menu. Test primary buttons, text links, icons and fields. Check normal and visited states and examine contrast against the backgrounds where each control appears.
The CSS selector :focus-visible lets you apply styles when the browser determines a focus cue should appear. Avoid removing outlines globally without a tested alternative. Check containers whose overflow clips an outline and styles that conceal it when modules overlap. If the current control is obvious only while the pointer is over it, return to the keyboard and inspect which state the theme is styling. Test with the pointer resting somewhere unrelated to the control.
07. Repeat in both directions and with magnification
Start from a reproducible state and record the browser, viewport size and zoom. Move forwards with Tab and back with Shift+Tab. Observe each control as it receives focus. Test near the upper and lower edges and when reaching the last element in a panel. Some layers cover controls only when moving backwards, as the browser scrolls in the opposite direction.
Repeat with the header expanded, the menu closed and any notices a visitor would see on the first visit. On a narrow or magnified display, text can wrap and reduce the available height. A short recording of the exact sequence helps distinguish a scroll jump from a change of focus. The expected outcome is concrete. The person can identify the current control before deciding whether to activate it.
08. Fix the Divi template and verify the journey
In WordPress, establish whether the header comes from the theme, a Theme Builder template or a module configured to stay fixed. Identify where its height is set and which rule governs scrolling. Correct the component causing the overlap and review pages that reuse it. Include at least one long page, a form and a journey involving in-page navigation.
An overlay can offer presentation adjustments, but the geometry of the header, focus sequence and reserved space belong to the page implementation. An automated tool may identify some individual problems. The test that closes this case is completing the booking again with the keyboard, seeing every step when it receives focus, and confirming you can move forwards or backwards without losing your place. Record the result alongside the original reproduction steps so it can be repeated after template changes.