Back to reviews and guides

WCAG 2.4.11 Focus Not Obscured (Minimum): Making Keyboard Focus Visible

WCAG 2.4.11 Focus Not Obscured (Minimum) requires that keyboard focus indicators remain visible and not be hidden by content or clipping. This article explains the requirement, common failures, practical CSS fixes, manual testing steps and a developer checklist to ensure focus stays visible at normal and zoomed views.

What WCAG 2.4.11 Focus Not Obscured (Minimum) requires

WCAG 2.4.11 Focus Not Obscured (Minimum) says the keyboard focus indicator must remain visible and not be hidden by other content when a user tabs to an element. The requirement aims to ensure people who rely on keyboard navigation can see where focus is at all times.

Who benefits and why it matters

Keyboard users, people with motor impairments, screen magnifier users and some cognitive impairment users benefit the most. If focus is invisible or clipped, a user can lose their place, trigger the wrong control, or get blocked from completing a task.

Key concepts you should understand

  • Focus indicator: a visible highlight that shows which element has keyboard focus.
  • Obscured focus: when the indicator is partly or fully covered by another element, clipped by overflow, or positioned offscreen.
  • Minimum versus Enhanced: Minimum requires the focus indicator itself remain visible. Enhanced requires the focused element and its contents to be fully visible.

How WCAG 2.4.11 differs from common focus rules

Many teams remove the native outline and forget to add a visible replacement. Others add a tiny 1px outline that is hard to see. WCAG 2.4.11 is not only about adding an outline. It also covers cases where the indicator gets hidden by layout decisions, overlays, sticky headers or overflow rules.

Practical CSS patterns that pass 2.4.11

Use these patterns as starting points. Keep the focus indicator large enough and ensure it can escape clipping.

  • Visible outline: :focus-visible { outline: 3px solid #1a73e8; outline-offset: 2px; }
  • Box shadow alternative: :focus-visible { box-shadow: 0 0 0 3px rgba(26,115,232,0.35); }
  • Prevent clipping: ensure parent containers do not hide overflow for focus crops. Prefer overflow: visible for containers that hold interactive elements.
  • Z-index for focus rings: if an overlay or sibling could cover the ring, increase stacking for the focused element or its ring. Use caution and test stacking contexts.

Common layout problems that hide focus and fixes

  • Sticky headers covering in-page anchors: add CSS like html { scroll-padding-top: 80px; } or use scroll-margin-top on the anchored element.
  • Overflow: hidden on parent: change to overflow: visible or move the focusable element outside the clipping container.
  • Transform or filter creating new stacking contexts: transforms can clip box-shadows and outlines. Place the focused element in a non-transformed container if possible.
  • Custom widgets that remove native focus: add a clear, visible focus state and test on keyboard only.

How to test WCAG 2.4.11 manually

Automated tools can flag some issues, but manual keyboard checks are essential. Follow these steps.

  1. Turn off the mouse. Use Tab and Shift+Tab only. Watch the visible focus as you move around the page.
  2. Open all dialogs, menus and overlays with keyboard controls. Ensure focus is visible when those controls open.
  3. Test with different zoom levels and desktop magnifier. Increase browser zoom to 200% and verify the focus indicator remains visible.
  4. Check in-page anchors. Press a link to a section and ensure the focus is not covered by a sticky header.
  5. Use browser devtools to force focus where needed. For example, run document.querySelector(‘selector’).focus() in the console and inspect the indicator.

Automated checks and tools

Use accessibility scanners like axe or Lighthouse to find obvious failures. Then follow with the manual tests above. No tool currently replaces the need to keyboard test at real zoom levels and with real overlays.

Testing checklist for developers and QA

  • Does every interactive element show a visible focus style when tabbed to?
  • Is the focus style not hidden by other elements or clipped by overflow?
  • Does keyboard focus remain visible when dialogs and menus open?
  • At 200% browser zoom, is the focus still visible?
  • Are in-page anchors adjusted for sticky headers with scroll-padding-top or scroll-margin-top?

Handling third-party widgets and embeds

You cannot always change third-party code. Use these strategies.

  • Wrap embeds in a non-clipped container so a focus ring can appear outside the embed boundaries.
  • Communicate with the vendor and request a visible focus state and no focus clipping.
  • Where vendor controls remain inaccessible, provide a clear skip link to a fallback control or the nearest accessible alternative.

Developer decisions: native outline or custom focus?

Keep three goals in mind: visibility, contrast and non-obscuring. Native outlines are reliable for visibility across devices. Custom styles give more design control but must meet the same visibility rules. If you replace the outline, ensure the replacement is at least as visible and cannot be covered by layout choices.

Common mistakes to avoid

  • Removing outline without adding a visible replacement.
  • Relying on color alone when contrast is insufficient.
  • Assuming automated tests guarantee compliance.
  • Using tiny outlines or 1px shadows that disappear under zoom or low contrast.

Quick remediation workflow

  1. Run an automated scanner to find missing focus styles.
  2. Keyboard test the page at 100% and 200% zoom. Note every obscured focus.
  3. Fix CSS: provide a robust :focus-visible rule, avoid overflow: hidden on parents, and add z-index or move elements to avoid overlays.
  4. Re-test keyboard navigation and zoom. Repeat until all focus is visible and not obscured.

Short checklist to hand to designers

  • Design focus states before removing native outlines.
  • Make focus states at least 3px thick or provide an outer glow so they remain visible at zoom.
  • Test designs with keyboard navigation and high zoom.
  • Avoid layouts that rely on clip, transform or overflow to hide elements that can receive focus.

Final notes

WCAG 2.4.11 is practical. It forces teams to think past cosmetic focus removal and consider layout consequences. The simplest path is to keep or replace the native outline with a clear, high-contrast, non-clipped focus indicator and to manual-test with keyboard and zoom.