Focus must not be covered by sticky or fixed chrome
Aliases: sticky header · scroll-padding · obscured focus
What it is
The ring can be bright and the replacement can be written, and focus can still be invisible — under a sticky header, a footer bar, a cookie strip, a chat bubble. When the browser scrolls a focused control into view, it uses the document viewport, not the slice taken by position: sticky / fixed. The keyboard is already on an input; the pixels on screen are navigation or an ad. Focus must not be obscured means the control and its indicator have to sit in the visible rectangle that chrome does not cover.
Why it happens
Scroll alignment delivers the target to the viewport edge by default. A sticky bar is pinned to that edge, so the top or bottom of the target (often the whole box) slides under the bar’s z-index. The ring is painted on the control’s box; the bar is another layer. No amount of ring contrast saves covered pixels. scroll-margin / scroll-padding redefine “the viewport” as the safe area after chrome, so alignment reserves the bar’s height.
A second layer is chrome that arrives later: a header that appears on scroll, an expanding cart footer, a cookie banner that paints after focus has already landed. Magnification makes the bar larger relative to the viewport, so covering is easier, but the root is still fixed layers versus scroll alignment, not type size. This is not a wrong focus order or a trap: Tab order can be perfect and the stop still sits under the bar.
Studying it
With sticky header and footer on, keyboard-walk a long form and in-page links. At each stop, test whether the control’s rectangle intersects a fixed layer. Compare obscured counts before and after scroll-padding-top/bottom.
Independent variables: chrome height, whether scroll-padding / scroll-margin is set, whether a banner appears late. Dependent variables: number of obscured focus stops, partial versus full cover, whether the indicator can be seen.
Re-walk after cookie and chat widgets arrive; do not test only the initial DOM.
Where it stops holding
A user-dragged magnifier covering focus is tool geometry, not page chrome. Focus left in an off-screen menu after close is focus management. A toast that covers for a second still counts if the user cannot operate the control underneath; a status bubble that does not steal interaction is a closer call. Focus inside a modal is held by the modal’s own layer, not by the page sticky bar — but a site footer stacked on top of the modal still covers.
Applying it
- Set
scroll-paddingon the root from the real sticky header and footer heights (orscroll-marginon targets) so focus scroll stops in the safe area. - Banners that arrive late must either enter the tab order and be dismissible, or must not cover current focus; if they do, yield the visible region.
- Do not park an undismissible chat button or ad on top of a focused control.
- Verify: keyboard-walk a long page with sticky header and footer. At every stop the control and its indicator sit fully between the two bars. Temporarily heighten the header; if covering appears at once, padding is not tracking height.