Focus Indicators Worth Having
Removing the default outline is still the most common accessibility mistake in CSS. What to replace it with, and what WCAG 2.2 now asks of the replacement.
For developers who want to:
- Understand why the default focus outline gets removed and what breaks
- Use focus-visible to satisfy both designers and keyboard users
- Build an indicator that meets the new WCAG 2.2 expectations
- Find the places where your focus indicator is hidden rather than missing
outline: none remains the single most common accessibility mistake in CSS. It is usually deliberate, usually made for a defensible reason, and usually not accompanied by a replacement.
Why it gets removed
The default outline appears when a mouse user clicks a button. It looks like a bug to a designer, because visually it is inexplicable — the user clicked, they can see what they clicked, and now there is a ring around it.
So it gets removed. And a keyboard user, who has no other way of knowing where they are on the page, is left navigating blind.
What solves the original complaint
:focus-visible matches only when the browser judges that a focus indicator should be shown — keyboard navigation, generally, and not a mouse click on a button.
This means you can style focus properly for keyboard users without the ring appearing on every mouse click. It is well supported now, and it removes the reason people reached for outline: none in the first place.
The pattern:
- do not remove the outline globally
- style
:focus-visibledeliberately - if you must remove the default, replace it in the same rule, not somewhere else
What the indicator needs to be
WCAG 2.2 added 2.4.13 Focus Appearance at level AAA, and even if you are not targeting AAA it is a good description of what "visible" actually means.
The substance of it:
Big enough. The indicator should be at least as large as a two-pixel-thick perimeter of the focused component. A one-pixel hairline is technically present and practically invisible.
Contrasting enough. At least 3:1 between the focused and unfocused states of the indicator area.
Against its background too. An indicator that contrasts with the button but not with the page behind it fails in practice.
A workable default: a solid outline of two to three pixels, in a colour with strong contrast against both the component and the page, with a small outline-offset so it is not swallowed by the component's own border.
The offset matters more than people expect. An outline drawn directly on the edge of a dark button on a dark background is very hard to see; two pixels of gap makes it obvious.
The failure nobody tests for
WCAG 2.2 also added 2.4.11 Focus Not Obscured (Minimum) at level AA, and this is the one most sites currently fail.
The indicator is present and correct. It is simply hidden behind something.
Sticky headers are the usual cause. Tab down a long page: at some point the focused element scrolls up under the fixed bar. Focus is there, the ring is drawn, and it is behind the header.
Cookie banners fixed to the bottom of the viewport do the same.
Non-modal dialogues and toasts likewise.
This does not show up when you check the top of a page. It only appears when you tab through a scrolled one, which is why it is so widespread.
The fix is usually scroll-margin-top on focusable elements matching the height of the sticky element, so that scrolling to a focused element leaves room for it.
Where to look in your own code
Four searches, in order of how often they find something:
outline: none and outline: 0 across your stylesheets. Every occurrence needs a replacement in the same place.
Component libraries. Many reset focus styles by default, and the reset is inherited by everything you build on them.
Custom controls. Anything built from a div with a click handler probably has no focus behaviour at all — which is a bigger problem than the indicator.
Skip links and off-screen elements. These are frequently positioned off-screen and never brought back, so the focus indicator is drawn somewhere nobody can see.
Checking it
Put the mouse down and press Tab, repeatedly, on a real page, scrolled.
You should be able to see where you are at every step, without hunting. If you lose your place even once, that is the finding — and it is likely to be either a missing indicator or a sticky element in front of it.
Two minutes, and it finds more than any scan.
[Suzanne: your existing keyboard and screen reader article covers navigation conventions; this is the CSS side of the same thing and could link to it. If you have a house focus style you use on client work, showing it here with the reasoning would be stronger than my generic recommendation.]