F78: When CSS Erases the Path for Keyboard Users

"The focus indicator is turned off with CSS." That's the entire description of Example 1 in WCAG Failure F78 (opens in new window). One sentence. One rule. One line of CSS that locks millions of keyboard users out of functional navigation.

F78 is W3C's official documentation of a failure pattern that appears in codebases everywhere: styling that removes or obscures the browser's default focus indicator without providing a replacement. It's not a subtle edge case. It's a foundational failure — and it maps directly to three separate success criteria in WCAG 2.2.

The Failure

F78 describes a failure condition that occurs when "the user agent's default visual indication of keyboard focus is turned off or rendered non-visible by other styling on the page without providing an author-supplied visual focus indicator."

The official W3C document identifies three distinct CSS patterns that trigger this failure:

Example 1: Outright removal

:focus { outline: none }

This is the bluntest form. The browser's focus ring — the visual signal that tells keyboard users where they are on the page — is simply switched off. No replacement. Nothing.

Example 2: Visual camouflage

a { outline: thin dotted black }

This one is subtler and arguably more insidious. The focus indicator still renders, but a permanent outline on link elements makes it indistinguishable from the focus state. Users can't tell which element has focus because every link looks focused all the time.

Example 3: Border occlusion

a { border: medium solid black }

The focus indicator is drawn just outside the element's border. When that border is thick, dark, and the same color as the focus ring, the ring disappears visually — absorbed into the border. Technically present. Functionally invisible.

All three patterns fail Success Criterion 2.4.7 Focus Visible (opens in new window) (Level AA). Examples 2 and 3 also fail SC 1.4.11 Non-text Contrast (opens in new window) (Level AA). And all three fail SC 2.4.13 Focus Appearance (opens in new window) (Level AAA), which sets specific geometric and contrast requirements for focus indicators in WCAG 2.2.

Why This Matters

For sighted mouse users, focus indicators are invisible infrastructure — they're there, but rarely noticed. For keyboard-only users, they're the entire navigation system.

Consider who depends on keyboard navigation: people with motor disabilities who cannot use a mouse, power users who prefer keyboard efficiency, switch device users who navigate sequentially, and people with tremors for whom precise mouse control is painful or impossible. When the focus indicator disappears, these users lose their place on the page. They're navigating blind — pressing Tab with no visual confirmation of where they've landed.

The problem compounds in complex interfaces. A modal dialog with no visible focus indicator. A multi-step form where Tab order is unclear. A navigation menu where the active item is invisible. Each of these becomes a barrier that may be impossible to overcome without abandoning the task entirely.

The camouflage pattern (Example 2) deserves particular attention. It creates a cognitive burden even for users who can eventually figure out what's happening — they must hold uncertainty about their position while simultaneously trying to complete a task. That's not accessible design. It's friction dressed up as style.

The Fix

The correction is straightforward: never remove the focus indicator without replacing it with something better.

Remove the suppression, or provide a visible replacement:

/* DON'T do this */
:focus { outline: none; }
/* DO this instead — a custom, high-contrast focus indicator */
:focus {
  outline:  solid ;
  outline-offset: ;
}

For links with permanent borders, differentiate the focus state clearly:

/* DON'T do this — permanent outline that mimics focus */
a { outline: thin dotted black; }
/* DO this — remove the permanent outline, style :focus distinctly */
a { outline: none; }
a:focus {
  outline:  solid ;
  outline-offset: ;
  border-radius: ;
}

For thick-border elements, ensure the focus indicator has sufficient contrast and area:

/* DON'T do this — border absorbs the focus ring */
a { border: medium solid black; }
/* DO this — use box-shadow to create an unambiguous focus indicator
   that sits outside the border with sufficient contrast */
a:focus {
  outline: none;
  box-shadow: 0 0 0  FFFFFF, 0 0 0  ;
}

The double box-shadow technique — a white gap followed by a colored ring — is particularly effective. It ensures the focus indicator is visible against both dark and light backgrounds by creating a contrast buffer.

For teams working toward full WCAG 2.2 compliance, SC 2.4.13 Focus Appearance (opens in new window) sets specific requirements: the focus indicator must have an area of at least the perimeter of the unfocused component multiplied by 2 CSS pixels, and must meet a 3:1 contrast ratio against adjacent colors. Custom indicators need to be designed to these specs, not just added as an afterthought.

Applying This

F78 is both easy to detect and frequently missed in automated testing — which is worth sitting with. The outline: none pattern is catchable by automated tools. The camouflage and occlusion patterns often aren't, because the tool sees a focus indicator present and moves on. This is exactly the detection gap documented in Beyond Detection: Why Context Separates Automated Testing from Manual Audits — automated scans can confirm the presence of a focus style, but can't evaluate whether that style is actually distinguishable in context.

For development teams, the practical approach:

• In code review: Flag any CSS rule touching outline on :focus or :focus-visible. Require justification and a visible replacement.
• In automated testing: Configure your linter or accessibility test suite to flag outline: none and outline: 0 globally. Tools like axe-core will catch the outright removal case.
• In manual testing: Tab through every interactive element. If you lose track of where you are at any point, you've found a failure. Do this with the browser's default styles first, then with your custom styles applied.
• In design: Build focus states into your component library from the start. Retrofitting focus indicators onto a mature design system is significantly harder than designing them in. Treat :focus-visible as a required state in every component specification.

The outline: none pattern often enters codebases for aesthetic reasons — designers find the default focus ring visually disruptive. The answer isn't suppression. It's replacement with something that works for everyone. A well-designed focus indicator can be a visual asset, not an eyesore.

Teams navigating multiple compliance frameworks — WCAG 2.1, WCAG 2.2, Section 508 — will find that focus visibility requirements appear across all of them, with slightly different specifications. The Compliance Framework Paradox examines how overlapping standards create implementation confusion, but F78 is one area where the standards converge clearly: visible focus is non-negotiable across every framework.

CORS Perspective

F78 is a failure with a clear operational signature: it almost always originates in a design decision, not a development oversight. From a strategic alignment standpoint, the fix requires getting designers and developers aligned on focus indicator standards before components are built — not after. The community impact is direct and disproportionate, falling hardest on motor-disabled users and keyboard navigators who have no workaround when focus disappears. From a risk standpoint, outline: none applied globally is the kind of finding that appears in DOJ investigations and settlement agreements (opens in new window) precisely because it's both pervasive and unambiguous. The operational win here is systemic: one updated design system token for :focus-visible fixes the pattern across every component simultaneously, making this a high-leverage, low-ongoing-cost intervention.