WCAG 2.4.13 Focus Appearance: What an Accessible Focus Indicator Looks Like

WCAG 2.4.13 defines requirements for focus appearance. This success criterion insists that keyboard focus must be easy to see and recognise on every interactive control. A visible focus indicator helps people who rely on keyboards, switches, or screen magnifiers to know where keyboard input will go.

What WCAG 2.4.13 expects (plain terms)

The rule asks for a focus indicator that is reliably visible across page backgrounds and states. It must not be hidden or removed for visual reasons alone. The indicator should be large enough to find, contrast with nearby content, and persist while the element has keyboard focus.

Key characteristics of an accessible focus indicator

• Clearly visible against the element and its background
• Distinct from hover or active states so keyboard users can follow focus
• Reliable across text, images and complex backgrounds
• Does not rely on colour alone to convey focus
• Maintains visibility when the page is zoomed or text size is increased

Good and bad examples (what to use and what to avoid)

Good examples

• Outline with offset: e.g. “button:focus { outline: 3px solid #0A66FF; outline-offset: 2px; }” so the ring sits outside the element edge
• Combined outline plus subtle box-shadow to create a clear ring on busy backgrounds
• Contrast-first approach: choose an accent that stands out against both light and dark backgrounds or switch style on transparent backgrounds
• Use :focus-visible so mouse focus is not confused with keyboard focus, while ensuring keyboard users always see the indicator

Bad examples

• Removing the default focus (outline: none) without providing an alternative
• Relying on colour alone, such as only changing text colour on focus
• Very thin or faint indicators that disappear on patterned images
• Indicators that are only visible on hover but not on keyboard focus

How to test focus appearance

Run both quick manual checks and automated checks. Manual testing finds real-world failures that tools miss.

Manual test steps

1. Tab through the entire page. Every interactive item must show focus in sequence.
2. Use Shift+Tab to check reverse order and visible focus on the previous element.
3. Open menus and dialogs. Confirm the focus ring appears on triggers and inside overlays.
4. Zoom the page to 200% and repeat. The focus must remain visible when text or layout scales.
5. Test on images and busy backgrounds. The indicator should not disappear or blend in.
6. Try a keyboard-only workflow for common tasks: form entry, link navigation, modal open/close.

Automated tools to supplement manual tests

• Browser accessibility extensions such as Axe or Accessibility Insights to catch missing focusable element issues
• Lighthouse accessibility checks for some focus-related failures
• Contrast tools to compare indicator colour against surrounding pixels when necessary

Implementation notes for common components

Links and native buttons

Keep the native focus unless you replace it with a stronger visual. For anchors styled as buttons, preserve keyboard focus and add a visible ring when focused.

Custom controls and non-native widgets

Ensure custom elements receive keyboard focus with tabindex=“0”. Do not use tabindex greater than 0. Add role attributes where semantics are not native but do not rely on ARIA alone to provide focus handling.

Form fields

Inputs must show focus even when they use custom borders or background images. If you change the field outline on focus, keep the new outline at least as visible as the default.

Common mistakes and how to fix them

• Removing focus outlines during visual polish. Fix: add a deliberate, high-contrast replacement.
• Using very light colours on pale backgrounds. Fix: pick a darker or contrasting accent or add an additional stroke.
• Relying solely on hover states. Fix: create separate focus styles and use :focus-visible to avoid mouse noise.
• Trapping focus inside a modal incorrectly. Fix: manage focus programmatically so focus moves into and out of overlays predictably.

Accessibility semantics and DOM considerations

Keyboard focus depends on the document structure. Ensure interactive controls are keyboard-focusable and in logical order. Use tabindex=“0” for custom focusable elements and avoid positive tabindex values. Use WAI-ARIA roles only to add semantics; they do not create focus unless the element is focusable.

Developer checklist (quick)

• Tab through every page and component
• Keep or replace default outlines with a clear alternative
• Use :focus-visible to separate mouse and keyboard focus where appropriate
• Check focus under 200% zoom and on complex backgrounds
• Make custom widgets focusable with keyboard and announce states with ARIA when needed

A visible, reliable focus indicator is a small change with big impact. Following WCAG 2.4.13 principles makes sites easier to use for people who cannot or prefer not to use a mouse. Test with real keyboard use, and keep your focus style consistent across the site.