Focus visible pass rate: a metric that catches what contrast ratios miss

WCAG 2.1 Success Criterion 2.4.7, Focus Visible, is a Level AA requirement, and 2.4.13 in WCAG 2.2 strengthens the expectation at AAA with size and contrast specifics for the indicator itself. Automated scanners detect the crudest failure, an outline removed with no replacement in CSS. They cannot judge whether a custom indicator is actually visible against the background it lands on, or whether a sticky header covers it. That judgement needs a keyboard and a person, which is why most dashboards skip the metric entirely.

The result is a reporting blind spot shaped exactly like a keyboard user experience of your site. Teams celebrate falling scanner errors while tab order dead ends and invisible focus persist in the flows that matter. A sampled, human checked pass rate closes that gap with a number leadership can track, and, more importantly, a list of failing elements a developer can fix.

Why this metric, and not another scanner count

Sample flows, not pages at random. Pick the five or six journeys that carry the business: browse to product, add to cart, checkout, sign in, account changes, support contact. In each flow, enumerate every focusable element in tab order: links, buttons, inputs, custom controls, cookie banner controls, chat launchers, the lot. The denominator is those elements. The numerator is those showing an indicator a tester can see at a glance, at normal zoom, without hunting.

Two sampling rules keep the metric honest. Include third party elements exactly as a user meets them: an invisible focus on a payment iframe or a reviews widget is a failure in your flow whatever the contract says. And sample in the default theme state users get, including any consent banner present, because banners are focusable interfaces too and notorious indicator erasers.

Defining the sample so the number means something

Every metric develops a borderline, and here it is the technically present indicator: a one pixel dotted outline in a grey that technically differs from the background. Decide the bar before you test, and write it down. A workable bar borrows WCAG 2.2 AAA thinking without claiming AAA conformance: the indicator should be at least two pixels thick, and its contrast against adjacent colours at least 3 to 1, the same ratio WCAG uses for non text indicators under 1.4.11.

Scoring borderlines without lying to yourself

Keep reading: Keyboard trap incidents: the accessibility metric that should always read zero, ARIA label coverage: when one hundred percent is the warning sign.

What to do with the first, bad number

Elements failing the written bar count as fails. Sounds harsh, and that is the point: a bar applied consistently across quarters gives you a trend you can trust, while tester by tester generosity gives you a number that improves whenever a kinder tester runs it. Record the failing element, the flow, and the reason in one line each. The list is the deliverable; the percentage is its headline.

A first honest pass rate under 90 percent on checkout is common, and the failures usually cluster: a global outline none in a reset stylesheet that custom components never replaced, one or two widgets, and sticky headers hiding indicators at certain scroll positions. The cluster is good news. Fixing the reset and the top two offenders often moves the flow rate more in a week than a quarter of one off tickets did.

Re sample after fixes on the same flows with the same bar, and report the delta with the failing list shrinking, not just the percentage rising. A pass rate that reaches the high nineties with two known legacy widgets named and scheduled beats a clean 100 percent nobody believes, including the team that produced it.

Frequently asked questions

What WCAG criterion covers visible focus indicators?

Focus Visible is WCAG 2.1 Success Criterion 2.4.7 at Level AA: any keyboard operable interface must have a mode where the focus indicator is visible. WCAG 2.2 adds 2.4.11 Focus Not Obscured at AA, covering indicators hidden by sticky headers or banners, and 2.4.13 at AAA with size and contrast specifics.

Can a scanner measure focus visibility for me?

Only the shallowest part. Scanners can catch CSS that removes outlines without replacement. They cannot judge whether a custom indicator is perceptible against real backgrounds, or whether page furniture covers it. A defensible pass rate needs keyboard sampling by a person, on real flows.

What is a good focus visible pass rate to aim for?

Treat anything under 95 percent on a revenue flow as work to schedule, and expect the first honest measurement to land lower than the team hopes. The goal state is effectively complete pass on core flows with any residual failures named, owned, and dated, not a percentage that hides them.

How often should the metric be re sampled?

Quarterly is a workable cadence for most teams, plus a re sample after any theme, header, or checkout change, since those are the changes that historically break indicators. Keep the flows and the scoring bar constant so the trend line means something.