The focus indicator.

The focus indicator is the visual mark that lets a keyboard user see which element is currently selected.

The focus indicator is the accessibility feature most often deliberately deleted on the web. The reason is almost always aesthetic: the browser’s default ring does not match the design, someone writes a CSS rule removing it, and from that moment the keyboard user navigates the site blind.

The tragic part is that the fix is not hard. Designing your own ring instead of removing the default is a few lines of work — it preserves the design and meets the criterion at once.

Three separate criteria

WCAG 2.2 treats focus in three separate success criteria, and each asks a different question.

1. 2.4.7 Focus Visible — AA. The keyboard focus must be visible. This is the base requirement.
2. 2.4.11 Focus Not Obscured (Minimum) — AA, new in 2.2. The focused element cannot be ENTIRELY covered by a sticky header, cookie banner or chat bubble.
3. 2.4.13 Focus Appearance — AAA, new in 2.2. A numeric floor for the indicator’s thickness and contrast: at least 2 CSS pixels thick and 3:1 contrast between the focused and unfocused states.

Together the three mean: the focus will be visible, will not be covered, and will be distinct enough. On most sites the first is met, the second breaks by accident, and the third is never considered.

Design instead of delete

The rule that removes the default focus ring is, written on its own, a criterion violation. But removing it and putting your own indicator in its place is entirely legitimate — and usually produces a better result, because the browser default knows nothing about your palette.

A good custom focus indicator has four properties.

1. Thick enough — at least 2 CSS pixels. A thin line disappears on low-resolution screens and under magnification.
2. Contrasting enough — distinguishable against both the focused element and its surroundings. 3:1 is the floor; higher is better.
3. Offset from the element — a few pixels of space between ring and element separates the indicator from the element’s own border.
4. Consistent everywhere — the same indicator on every component. A focus that changes per component makes it harder to learn.

On this site the focus ring uses the accent color, and that color measures 10.22:1 against the paper ground. The thickness is 2 pixels. It meets both 2.4.7 and the numeric floor of 2.4.13 — and that is the result of a single token decision.

Separating mouse from keyboard

The real complaint behind the urge to remove the focus ring is usually this: the ring also appears when a button is clicked with the MOUSE, and there it looks unnecessary. The complaint is fair — a mouse user has no need for a focus indicator.

Modern CSS solves exactly this. There is a selector that shows the focus ring only when arriving by keyboard, and the browser decides based on the user’s input method. Click with the mouse and no ring appears; arrive with Tab and it does.

This is the technical answer to the “let’s remove the ring” debate: no need to remove it — conditioning it is enough. And one important warning — for older browser support, the general focus selector must be kept too; leaning only on the new selector leaves the focus entirely invisible in browsers that do not support it.

Removing the focus ring is not a design decision; it is removing a group of users from the site.

The sticky header trap

2.4.11 is the most frequently broken new clause of WCAG 2.2, and the cause is a widespread design pattern: the header that stays on top as the page scrolls.

The scenario: the user Tabs down the page. The browser scrolls to bring the focused element into view — and places it exactly under the sticky header. The element is technically “in the viewport”; for the user it is invisible.

The fix is handled with a single CSS property: focusable elements are given a margin to be kept above them while scrolling, set larger than the header’s height. The browser accounts for that space when bringing the element in.

The same trap exists at the bottom edge: a fixed cookie bar or chat bubble covers the elements at the foot of the page. Testing is simple — walk the page with Tab and make sure you can SEE the focused element at every step. Every step where you cannot is a violation.

Focus management: layers and dialogs

Focus must not only be visible; it must also be in the right place. Where the focus goes when a layer opens completely determines the keyboard user’s experience.

The correct behavior: when the layer opens, focus moves inside it; while it is open, Tab cannot reach the content behind; and when it closes, focus returns to the element that opened it. The third part is the most often skipped — focus drops to the top of the page and the user loses their place.

The balance to watch: keeping focus inside the layer is necessary, but blocking the exit via Escape is a 2.1.2 violation. Focus should cycle within the layer, yet the user must always be able to close it. The two do not conflict — one is containment, the other is the escape route.

The focus ring and design: a false conflict

The rationale behind deleting the focus indicator is almost always aesthetic, and that rationale constructs a conflict between design and accessibility that does not exist. The browser’s default ring genuinely clashes with most designs — blue, thick, hard-cornered. But what the criterion asks for is not that ring; it is A visible indicator.

The indicator can take many forms, and none has to break the design. A thin outline in the element’s own accent color, a distinct change of ground color, a thickened underline, or an offset ring around the element — all are valid, and all can be designed to your palette. The only constraint is numeric: thick enough and contrasting enough.

On this site the focus ring uses the page’s single accent color, and that color is already defined in the palette. The focus indicator is not a foreign element imported from outside the design; it is part of the design language. Two pixels thick, 10.22:1 against the paper ground — comfortably meeting both 2.4.7 and the numeric floor of the AAA-level 2.4.13, at no visual cost.

The problem is not that the focus ring is ugly; it is that you have not designed your own.

The only reliable way to test

Focus indicator defects are almost never caught by automated tools. For a tool to answer “is the focus visible,” it would have to render and compare the focused and unfocused states — doable, but most common tools do not do it. So the method stays manual and consists of three steps.

1. Walk the page with Tab, start to finish — can you SEE where the focus is at every step? Every step where you cannot is a 2.4.7 violation.
2. Repeat the tour with the page scrolled — does the sticky header or bottom bar cover the focused element? If it does, that is a 2.4.11 violation.
3. Walk the dark and light themes separately — a ring with enough contrast in one theme can fall below the threshold in the other. Two themes are two separate measurements.

The third step is the most skipped. Most teams adding dark theme support review the text colors and forget the focus ring; the result is a focus indicator nearly invisible on the dark ground. Because the defect affects only keyboard users and only in the dark theme, it can live unnoticed for months.

The lasting fix is binding these three steps to a test. That the focused element really carries a visible indicator, and that the indicator’s contrast stays above the threshold, can be verified automatically on every deployment. Testing by hand once passes — and silently breaks with the next component.