The Focus Indicator Nobody Designed On Purpose

ClearPath Team · 2026-08-30 · 7 min read

Somewhere in your CSS file there's probably a line that reads outline: none or outline: 0. A designer added it years ago because the default blue box around buttons and links looked clunky against the brand colors. Nobody replaced it with anything. That one line quietly locks out every keyboard user who visits your site.

Focus indicators don't get much attention because sighted mouse users never see the problem. You click, you scroll, you never tab through a page. But for anyone navigating by keyboard, whether because of a motor disability, a screen reader, or just personal preference, the focus indicator is the only way to know where they are on the page.

Why this one detail matters so much

The focus indicator is to keyboard users what the mouse cursor is to mouse users, and just like you would never want to hide the mouse cursor, you never want to hide the focus indicator. Imagine your cursor vanishing every time you moved the mouse. You could still click things, technically, but you'd have no idea what you were about to click. That's what a stripped focus style does to someone tabbing through your navigation, your form fields, and your checkout button.

These outlines can be hidden by applying outline:0 or outline:none CSS to focusable elements, and that single override is one of the most common accessibility failures on the web. It's also one of the easiest for anyone to spot. Anyone can test keyboard accessibility by simply pressing the Tab key. If they get trapped or can't reach content, it's a clear violation. Plaintiffs' attorneys know this too. Keyboard accessibility is cited in 80% of ADA website lawsuits, and plaintiffs' attorneys actively test websites for keyboard issues because they're easy to detect and clearly violate WCAG.

What WCAG 2.2 actually added

WCAG 2.0 and 2.1 only required that a focus indicator exist somewhere, in some mode. That vague standard let a lot of barely-visible outlines pass. WCAG 2.2 tightened things up with three new success criteria built specifically around focus:

• 2.4.11 Focus Not Obscured (Minimum), Level AA: When a user interface component receives keyboard focus, at least a portion of it must remain visible and not be hidden by other content you provide. Sticky headers, cookie banners, and chat widgets are the usual culprits here.
• 2.4.12 Focus Not Obscured (Enhanced), Level AAA: When a user interface component receives keyboard focus, none of the focus indicator may be hidden by your content.
• 2.4.13 Focus Appearance, Level AAA: Focus indicators must have sufficient color contrast between the focused and unfocused states and must be of a sufficient size so as to be clearly visible.

That last one comes with real numbers attached, not just "make it visible." Focus indicators must be thick enough (at least 2px), large enough to cover significant area, and high-contrast enough (3:1 minimum) to be easily visible. A thin one-pixel outline in a pale gray that used to pass the old wording now fails outright.

The everyday ways focus breaks

Most sites don't fail on purpose. Focus problems creep in through small decisions that seemed harmless at the time:

• The reset stylesheet strips it. A lot of CSS resets zero out default browser styling, including outlines, and nobody adds a replacement.
• Custom components skip it entirely. Just as sighted users would be lost without seeing where the mouse pointer is, keyboard users rely on focus indicators to navigate effectively, and browser defaults usually handle native elements well, but when you create custom components, that's where things can break. A styled dropdown built from a <div> instead of a <select> often has no focus state at all.
• Sticky headers cover the focused element. A user tabs to a link and a fixed navigation bar sits right on top of it, hiding the outline completely. That's exactly the scenario 2.4.11 addresses.
• The outline blends into the background. A blue outline on a blue button might technically exist but fails the 3:1 contrast requirement, so it's invisible in practice.

Fixing it isn't complicated, but it does mean touching the code

The good news is that focus indicators are one of the more straightforward fixes in accessibility work, at least compared to something like reworking a whole page's markup. It usually comes down to CSS: restore a visible :focus-visible style, make sure it's at least 2 pixels thick with solid contrast against the background, and check that no sticky element covers it when a user tabs through the page. The visual presentation of components must have a contrast ratio of at least 3:1 against adjacent colors, and if your outline or highlight is too faint, it fails accessibility even if it technically exists.

Where it gets more involved is custom components. A styled dropdown, a card that acts like a button, or a custom date picker all need focus states built in by hand, along with proper tabindex and keyboard handling so the element can receive focus at all. That's a development task. No visitor-facing tool can add a missing focus style to a component that was never coded to accept one in the first place.

A five-minute test worth running today

You don't need a formal audit to catch the worst of this. Unplug your mouse, or just don't touch it, and press Tab from the top of your homepage. Watch for three things: does something visibly change as you move from link to link? Is that change easy to see against the background? And does anything, like a sticky header or a promo banner, ever cover the element you just tabbed to? You can spot-check by unplugging your mouse and trying to navigate with the keyboard only, and for most sites, this single test surfaces the problem faster than any scanner.

If you find gaps, prioritize the ones on your primary navigation, your forms, and your checkout flow first. Those are the paths a keyboard user has to get through to actually use your site, and they're also the paths most likely to end up screenshotted in a demand letter.