Keyboard Focus Behind Sticky UI: Can Users Still See Where They Are?

The website looks polished in a screenshot. The header stays visible while scrolling, a consent banner sits at the bottom, and a chat widget waits on the right. Then somebody navigates using only the keyboard.

Tab, Tab, Tab — and suddenly it is no longer clear which element is active. The link is fully behind the sticky header. A form field disappears beneath the consent banner. Or focus moves into content covered by an expanded chat panel.

This is not a cosmetic edge case. A person navigating by keyboard needs to see where the next interaction will happen. WCAG 2.2 added Success Criterion 2.4.11, Focus Not Obscured (Minimum), at Level AA for exactly that problem.

The practical audit question is: when focus moves to a control, is that control actually perceivable in the current viewport, or merely technically focused?

What WCAG 2.2 actually requires

Success Criterion 2.4.11 requires that when a user interface component receives keyboard focus, it is not entirely hidden by author-created content. W3C summarizes the goal as keeping the focused item at least partially visible.

That is deliberately a minimum. WCAG 2.4.12, Focus Not Obscured (Enhanced), is Level AAA and requires that no part of the focused component be hidden by author-created content.

The distinction matters: at AA, the focused control must not disappear completely; at AAA, it should remain fully visible. W3C explicitly identifies sticky footers, sticky headers, and non-modal dialogs as common content that can overlap focused items, and uses cookie banners as a concrete example.

For product teams, that suggests a better quality target than barely passing: design focus so users can track it without having to infer where it went.

Red flag 1: The sticky header beats browser scrolling

A common failure appears during focus movement rather than manual scrolling.

The browser attempts to bring a newly focused element into view. A position: fixed or position: sticky header, however, is part of the overlay system created by the site. If the browser scrolls the target to the top edge of the viewport and 96 pixels of navigation sit there, the focused element can end up underneath it.

W3C documents this exact class of failure in Technique F110: a sticky header or footer that completely hides focused elements while the user tabs can fail 2.4.11.

Do not test only whether the header remains visible while scrolling. Test forward tabbing, Shift+Tab back up the page, skip links, in-page anchors, focus after form errors, and states where the header changes height on mobile, under zoom, or after sign-in. A hard-coded offset may fit one state and be wrong in the next.

Red flag 2: The consent banner is “only at the bottom” until focus gets there

A non-modal banner can occupy a modest-looking part of the screen while completely covering several controls underneath.

W3C explicitly uses a sticky cookie banner as an example: when it completely obscures a focused component, it can fail 2.4.11. W3C describes true modality or adequate scroll spacing as possible approaches.

If the banner is modal, it should behave like a modal: focus belongs inside the dialog and the underlying page is not keyboard-operable while the decision is active. If the banner is intentionally non-modal, the page underneath can remain operable, but layout and scrolling must account for the space the banner occupies.

The risky middle ground is a large overlay that leaves the background in the tab order while covering enough of it to hide the active control.

Red flag 3: The chat widget grows, but focus logic knows nothing about it

A collapsed chat launcher may be tiny. An opened chat window can cover a third of the viewport.

WCAG explicitly considers content that users open themselves. Such content can obscure the focused component in some circumstances if the user can reveal that component without advancing keyboard focus — for example by using Escape to close the overlay or another immediately available keyboard action.

For chat, feedback, support, mini-cart, and similar overlays, ask: Does the overlay stay open after focus leaves it? Can it be dismissed with Escape? Does it cover controls on narrow screens? Can focus move behind it while the user cannot see the newly focused element? Does the widget become disproportionately large at 200 or 400 percent zoom?

An overlay that can only be closed with a small pointer-operated X does not solve the keyboard problem.

Red flag 4: The component is visible, but the focus state is not

SC 2.4.11 primarily evaluates whether the component is completely obscured. That is not identical to asking whether its focus indicator is easy to see.

W3C notes that Focus Visible, Non-text Contrast, and at AAA level 2.4.13 Focus Appearance may also apply. A translucent or blurred overlay can leave the component technically recognizable while making the focus indicator difficult to detect.

A useful audit therefore separates two questions: Is the focused component visible? Is the focused state on that component clearly perceivable? A strong focus ring does not help when the entire control is behind a sticky bar.

scroll-padding: a small CSS primitive with a large effect

For fixed headers and footers, scroll-padding is a particularly useful primitive.

The CSS Scroll Snap specification defines scroll-padding beyond snapping layouts. It establishes the optimal viewing region of a scroll container and explicitly mentions fixed-position toolbars and sidebars as areas authors may want to exclude from that region. This affects scroll-into-view behavior associated with targeting and focus.

W3C lists scroll-padding in Technique C43 as a sufficient technique for both 2.4.11 and 2.4.12. The model is simple: if a fixed header occupies the top of the viewport, the scroll container gets a matching safe region at the block start; a fixed bottom bar needs equivalent consideration at the block end.

But do not blindly hard-code a desktop header height. Headers, banners, and toolbars change across breakpoints, text enlargement, translations, signed-in states, and dynamic notices. If the overlay height varies, the scroll-safe region needs to remain correct as it varies.

scroll-margin can also be useful on specific targets such as headings or form-error destinations. The CSS specification defines it as additional space considered around an element for relevant scroll-into-view behavior.

A 15-minute audit without a specialist tool

Automated accessibility scanners can find many problems. Focus obscuration, however, depends heavily on focus order, viewport, state, and scrolling. A manual keyboard run is therefore essential.

1. Reload the page and use Tab through every interactive element without touching the mouse. Watch whether each target is scrolled into a usable part of the viewport.
2. Run the same path backwards with Shift+Tab. Sticky headers often fail only when navigation moves upward.
3. Open every persistent overlay: consent banner, chat, feedback widget, mini-cart, sticky promotion, support panel, and filter drawer.
4. Exercise long forms and force validation errors. If focus jumps to an invalid field or error summary, verify that the destination is visible after the jump.
5. Test tables of contents, skip links, and hash navigation. Fixed headers commonly cover these targets.
6. Test a mobile-sized viewport and at least 200 percent zoom; where possible, test 400 percent. A compact banner can become much taller once text wraps.
7. Change application state: signed in, signed out, before and after consent, with support widgets open, and with validation messages visible.

Why screenshots and scores miss this easily

A screenshot captures one state, not a focus journey. An automated scan may identify missing focus styles or semantic defects. Whether a particular control lands beneath a dynamic header on the seventeenth press of Tab depends on scroll position, viewport size, open overlays, focus sequence, and current layout state.

That is why “Accessibility 100” is not a substitute for asking: Can I use this entire page with a keyboard and always tell where I am?

This also matters to conversion. A covered Continue button, an invisibly focused form field, or an error target hidden behind a banner rarely produces a dramatic crash. People simply stop.

Put the solution in the design system

If the same headers, banners, and overlays appear across dozens of pages, the fix should not be reinvented for every landing page.

A robust design system should define a shared strategy for fixed and sticky UI, central scroll-padding or offset behavior, visible focus indicators, modality rules for dialogs and consent flows, keyboard dismissal for persistent overlays, and tests for forward and reverse navigation across viewports and zoom levels.

A small end-to-end test can exercise critical keyboard journeys and assert that the active element remains inside the usable viewport after focus changes. That does not automate accessibility as a whole, but it can reliably catch a recurring class of overlay regressions.

What Website-Pflichtencheck would inspect

A focus-and-overlay audit looks beyond whether a :focus style exists. Depending on the website, the review can cover focus order, forward and reverse keyboard navigation, sticky headers and footers, cookie and consent banners, chat and support widgets, non-modal overlays and drawers, skip links, focus after form validation, narrow viewports and zoom, scroll-padding, focus-indicator visibility and contrast, and differences between responsive or authenticated states.

The useful output should not stop at “WCAG issue: yes/no.” A better result is prioritized: where do users genuinely lose their place, which component causes it, and which change fixes the behavior system-wide rather than on one page?

Focus that the browser has technically assigned is not automatically usable focus. If the person cannot see where the keyboard is, the interface has lost its current point of interaction.

Sources

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
• W3C WAI: Understanding SC 2.4.11 Focus Not Obscured (Minimum) — https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html
• W3C WAI: Understanding SC 2.4.12 Focus Not Obscured (Enhanced) — https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced.html
• W3C WAI: Technique C43 — https://www.w3.org/WAI/WCAG22/Techniques/css/C43
• W3C WAI: Failure F110 — https://www.w3.org/WAI/WCAG22/Techniques/failures/F110
• W3C: CSS Scroll Snap Module Level 1 — https://www.w3.org/TR/css-scroll-snap-1/

Note: This article is a technical overview of WCAG 2.2 and does not constitute legal advice.