When a fixed bar hides keyboard focus: a practical audit

Identify the failure

A customer who moves through an online booking page with Tab can land on a link that is technically focused but physically behind the fixed header. The next keypress may still activate that link, yet the person cannot see what will happen. WCAG 2.2 success criterion 2.4.11, Focus Not Obscured (Minimum), asks whether the focused user interface component is entirely hidden by content created by the site. It is an AA criterion. The test concerns the component, not every pixel of the decorative focus ring. A partly visible component can meet this specific minimum, although leaving most of it covered is a poor practical result.

Keep this decision separate from the question of whether a focus indicator exists. WCAG 2.4.7 also requires a mode where keyboard focus is visible. A link might remain partly exposed while its only indicator is hidden under an overlay, creating another failure. Conversely, a brightly outlined area does not rescue a component that has disappeared behind a sticky footer. During review record the actual focused element, its position, the overlapping layer and whether either the element or indicator can be perceived. That evidence is more useful than a screenshot of the normal, unfocused page.

Map the layers that can cover controls

Start with a short inventory of the page rather than changing CSS immediately. Note sticky navigation, promotional bars, cookie notices, chat panels, bottom action strips and any non-modal dialog that stays open while the visitor moves elsewhere. Identify which layers appear only after scrolling, on a narrow viewport, after consent choices or while a form is incomplete. Record whether the layer is fixed to the viewport or belongs to a smaller scrolling container. The distinction matters because a scroll offset on the document cannot necessarily fix focus inside a separately scrolling panel.

For each layer, choose a representative control immediately before, within and after its overlap area. A business page may have a header that behaves well while tabbing forward but hides links when the user reverses direction with Shift and Tab. A bottom consent strip may cover the last form field, the submit button or a validation link near the footer. Test the actual combinations that customers can create. If a chat panel is user-opened, check how it closes and whether the focused item can be revealed without moving focus; that specific exception is described by the W3C guidance.

Run a keyboard route, not a static inspection

Open the page at its normal starting position and use only the keyboard to reach the first meaningful task. Tab through navigation, main content, form actions and footer, then reverse through the same route. When focus approaches an overlay, stop before pressing the next key and look for the focused component itself. Repeat after scrolling to the middle and near the bottom because sticky behaviour often starts only beyond a threshold. A pass on the opening screen says little about the state after a long product or application page has moved underneath the header.

Repeat at a narrow viewport and a short viewport, including a landscape phone shape and a zoomed desktop view. The test is about available space, not merely device branding. Switch between English and Traditional Chinese because different label lengths can change header height or cause a bar to wrap. Open persistent notices that would appear in normal use. Record the viewport, language, overlay state, key direction and obscured control for each defect. This gives the developer a reproducible case and prevents a correction tuned only to one screenshot width.

Choose a repair that fits the layout

W3C technique C43 demonstrates using space and CSS scroll-padding so content can scroll clear of a fixed banner. Apply the offset to the scroll container that actually moves, and account for the current height of the header or footer plus a modest gap. A hard-coded desktop value can fail when translated navigation wraps onto two lines. Check focus after browser scrolling, a direct in-page link and a script that moves focus, because they may take different routes. Verify the final position visually; the presence of a scroll-padding declaration alone is not a result.

Sometimes the more reliable repair is to stop fixing the layer at constrained sizes, reduce its footprint or let opened content push the page aside instead of covering it. A consent banner that occupies most of a short viewport may leave too little usable space even with a scroll offset. If a true modal is appropriate for the task, it must move focus into the dialog and keep keyboard navigation there until dismissal; merely styling an overlay as a dialog is insufficient. Choose the pattern that preserves the customer journey and test it with pointer and keyboard users.

Work through a booking-page example

Imagine a small clinic booking page with a sticky header and a bottom help banner. The customer has chosen a service and is moving backward from the confirmation button to correct a date. On a short laptop viewport the date field gets focus but sits entirely under the header. First reproduce the state and confirm the selected field through the browser inspector; do not infer focus from where the pointer rests. Next measure the current rendered header height, add scroll clearance to the page container and repeat Shift and Tab. If the banner also covers confirmation, treat its bottom overlap separately.

Now switch the booking page to Traditional Chinese and allow the browser to zoom. If the header grows, the same offset may no longer protect the date field. If the banner becomes taller, the confirmation button may move into its covered area. A good acceptance result is that a customer can travel from the service choice to the date and confirmation action in both directions, see the focused component and its indicator, and complete the task without guessing. Record this as a repeatable route rather than claiming the entire site conforms from one page.

Handle exceptions without overclaiming

The minimum criterion permits partial visibility of the focused component. It also treats user-movable content at its initial position, and allows some user-opened content to cover focus when the user can reveal the component without advancing focus. These are precise boundaries, not a licence to leave important controls hard to find. If a customer must discover an undocumented shortcut, or must move focus away and back before knowing where they were, the experience still needs work. Aim for the whole control and indicator to be plainly visible wherever the design permits.

A common mistake is to hide the focus outline to make a collision seem cleaner. That removes feedback without moving the component. Another is to add a large global scroll offset that disrupts anchor links elsewhere on the site. Treat each change as a layout decision: identify the affected scroll container, check all entry points, and revisit the behaviour when the header changes. Where a floating panel persists, define its close action in the interface and test that the focused item is revealed as W3C describes.

Set a useful acceptance record

Ask the team to attach a short route to the change request: page and language, viewport state, active overlay, starting control, keys pressed and expected final position. For a checkout or booking flow, include at least the normal path and one recovery path such as revisiting a field after an error. Watch both the component and its visible focus indication. If a developer reports that an automated checker found no issue, still execute the route manually; a checker cannot know every transient banner state or whether a particular customer task remains understandable.

Close the issue only after the tested route works in both languages and the constrained layout that originally failed. Record which fixed layers were examined and what remained outside scope, such as a separately managed third-party widget. If that widget can still cover an essential control, escalate the integration decision rather than writing a false all-clear. The operational next step is simple: retain the route as a regression check whenever navigation height, consent design or a floating customer support tool changes.

For a release handoff, show the test in a short recording or paired screenshots that include the focused control and the overlapping layer. Note whether the control was reached by Tab, Shift and Tab, an in-page link or a programmatic focus move. Those routes can produce different scroll positions. If the repair uses scroll padding, ask someone who did not implement it to repeat the route at a second viewport height and in the other language. If the tester must scroll manually after every focus change, the layout still puts the burden on the customer. Keep the result tied to this page and state; a global accessibility badge would claim more than the evidence supports.