Turn Focus Not Obscured Findings into Accessibility Tickets

A focus-not-obscured issue is easier to fix when the ticket names the sticky UI, viewport, zoom state, and exact focused control that gets covered.

Use this guide for WCAG 2.2 findings about keyboard focus hidden by sticky headers, cookie banners, chat widgets, fixed checkout summaries, overlays, clipped containers, or scroll positioning.

Open this focus-not-obscured finding in the generator

What to capture from the finding

Obscuring UI: sticky header, floating checkout summary, chat launcher, cookie banner, modal edge, or fixed footer.
Covered control: the exact button, link, field, menu item, or custom widget state whose focus is hidden.
Test conditions: viewport size, zoom level, browser, operating system, scroll position, and whether an overlay was open.
Actual focus evidence: whether the label, focused element, focus ring, or both are covered or clipped.
User task impact: uncertainty about current position, accidental activation risk, repeated tabbing, or blocked checkout/form progress.

Ticket structure

Title:
[Severity] Page or component: focused control is obscured by [sticky UI / overlay / clipped container]

User impact:
Explain what keyboard or switch users cannot see when focus moves to the affected control.

Evidence:
- Page or flow:
- Obscuring UI:
- Focused control:
- Viewport and zoom:
- Browser or device:
- Keyboard path:
- Actual result:
- Expected result:

Likely WCAG references to verify:
- 2.4.7 Focus Visible, when the focus indicator is missing or visually hard to identify.
- 2.4.11 Focus Not Obscured (Minimum), when the focused component is at least partly hidden by author-created content.
- 2.4.12 Focus Not Obscured (Enhanced), when the target standard requires the whole focused component to remain visible.

Acceptance criteria:
- The focused control and its focus indicator remain visible in the reported viewport, zoom state, and overlay state.
- Sticky or floating UI does not cover the focused component during keyboard navigation.
- Scroll positioning accounts for sticky headers, banners, and fixed footers.
- The retest uses the original keyboard path and at least one representative repeated instance if the same component pattern appears elsewhere.

Paste your focus-obscured note into the generator when you want this structure drafted from raw audit text.

Example conversion: sticky checkout summary

Raw note:
At 400% zoom in checkout, the sticky order summary covers the focused Continue to payment button. The user can activate the button, but cannot see which control currently has focus.

Developer ticket:
[High] Checkout shipping step: sticky order summary obscures keyboard focus on Continue to payment

User impact:
Keyboard and switch users may lose track of their current position in checkout because the focused primary action is covered by sticky content.

Evidence:
- Flow: checkout shipping step
- Obscuring UI: sticky order summary
- Focused control: Continue to payment button
- Test condition: 400% zoom, narrow viewport
- Keyboard path: Tab through the shipping form to the primary action
- Actual result: the button label and focus indicator are partly hidden below the sticky summary
- Expected result: the focused button and focus indicator remain visible

Likely WCAG references to verify:
- 2.4.7 Focus Visible
- 2.4.11 Focus Not Obscured (Minimum)

Acceptance criteria:
- The Continue to payment button is fully visible when it receives keyboard focus at the tested zoom and viewport.
- Sticky checkout UI no longer covers focused controls in the same flow.
- The fix is retested with keyboard-only navigation from the first shipping field to the primary action.
- The focus indicator remains visible and is not clipped by parent containers.

Common fix directions

Reserve scroll space: account for sticky headers, fixed footers, and banners when scrolling focused controls into view.
Avoid clipping focus indicators: check parent containers with overflow, transforms, masks, and custom outline offsets.
Handle open overlays: cookie banners and chat widgets should not cover the current focus target or force users to guess their position.
Retest at zoom: focus-obscured bugs often appear only at 200% or 400% zoom, not on a default desktop viewport.
Fix the component pattern: if a sticky header hides one focused card action, inspect repeated lists, product grids, and checkout summaries that use the same layout rule.

Paste-ready input for the generator

Focus not obscured finding:
Page or flow:
Obscuring UI:
Focused control:
Viewport and zoom:
Browser or device:
Keyboard path:
Actual focus visibility:
Expected focus visibility:
Relevant selector or component:
Repeated instances to inspect:

Open the accessibility ticket generator and paste this structure with the audit note.