Does your sticky header hide the control selected by the keyboard?
A page can appear usable with a mouse while a keyboard-selected control slips behind its sticky header. The visitor loses track of the current target or activates the wrong action. This guide examines one specific question rather than auditing every accessibility requirement: does the page’s own fixed content obscure the control receiving keyboard focus? Test the answer using real content and different screen conditions, including the states in which the header changes size or position.
1. Follow the focus order and the visible area together
Reload the page and put the mouse aside. Move through links and form controls with Tab, then reverse the direction with Shift+Tab. At each step, identify the focused control and check whether it is visible. Testing only the top of a page is not enough. Repeat the exercise midway through a long service description, at the beginning of a form and near the footer. If the header shrinks or becomes sticky after scrolling, test both states. Record a missing focus indicator as a separate issue.
2. Distinguish the minimum requirement from a better experience
W3C’s explanation of WCAG 2.2 Focus Not Obscured (Minimum) requires the focused component not to be entirely hidden by author-created content. Partial visibility can meet this minimum, while full visibility is a better usability target. A thin visible edge of a link may still leave its wording unreadable. Your team can therefore choose an acceptance target stronger than “not completely missing.” Ask whether the control’s label, focus indicator and intended action are understandable together. Be precise about which criterion a test supports rather than treating one observation as a complete accessibility verdict.
3. Measure the space used by fixed layers together
Imagine an enquiry page with a sticky menu at the top and a contact bar at the bottom. Each can seem small by itself, yet together they reduce the usable area in a short window. Try mobile landscape, enlarged text and any open notification banners. Activate the relevant fixed elements together and move through the form. A repair based only on a tall desktop viewport can create a new overlap elsewhere. If a persistent contact button covers the field a visitor wants to complete, reconsider its position or fixed behaviour.
4. Spacing can help, but test the resulting behaviour
A developer may consider scroll-padding-top on the actual scrolling container to account for the fixed upper layer. MDN describes it as setting an offset for the optimal viewing region. Do not treat one CSS declaration as a universal repair. Nested scrolling areas, changing header heights and different focus movements need testing. Reducing the amount of fixed content or changing its size may be more appropriate. After the adjustment, repeat both forward and backward keyboard navigation, including states where form validation messages are visible and alter the layout.
5. Record the exact control and screen conditions
Include the page address, control name, navigation direction and viewport size in the issue record. Before-and-after evidence should use the same conditions. Do not approve the repair only because the header looks attractive; complete the task with the keyboard. This limited check does not certify the entire site against WCAG. Add it to the acceptance scenarios for a web design project. The sticky mobile action guide addresses placement. The decisions complement one another: where the persistent action belongs and whether it obscures other controls both need explicit review.
Frequently asked questions
Is a small visible part of the control enough?
This minimum WCAG criterion addresses complete obstruction. Making the target, wording and focus indicator fully understandable is a better practical acceptance target.
Is adding scroll-padding-top sufficient?
Not in every case. Retest the actual scrolling container, changing header height and forward and backward keyboard navigation.