Focus Visible Failure Rate: The Metric That Predicts Keyboard Complaints

Every accessibility program has met this defect one complaint at a time: a keyboard user tabbing through a checkout who cannot tell where they are. Focus visible failures feel anecdotal because they are usually discovered anecdotally, in a support ticket or a lawsuit exhibit. They do not have to be. The failure is countable across a whole site, and as a rate it behaves like the other metrics in this series.

WCAG success criterion 2.4.7, Focus Visible, is Level AA: any keyboard operable interface must have a mode of operation where the focus indicator is visible. The criterion is binary per element. Counted across templates, it becomes a rate, and the rate predicts the complaints with embarrassing accuracy.

How to count it without fooling yourself

The method is a scripted tab pass plus human verification, in that order. Automated checks catch the crudest case, outline set to none with no replacement, but they cannot judge whether a two pixel colour shift on a low contrast background is perceivable in practice. Run the automation to find suspect components, then tab through the templates yourself and mark each interactive element type pass or fail at the component level, not the page level.

Count unique components, not instances. One broken button component repeated on four hundred pages is one failure with four hundred exposures, and reporting it as four hundred failures inflates the number while hiding the fix. Our error identification rate work in Error Identification Rate: Do Your Forms Tell People What Went Wrong used the same component level counting for the same reason: rates should describe the system, not the site size.

What the rate usually looks like

The failures cluster predictably. Custom controls built from divs, icon only buttons, card components where the whole card is a link and the focus ring lands on an invisible wrapper, and anything where a design system update reset the default outline and nobody noticed for two releases. Header and footer components are disproportionately guilty because they are built once, styled hard, and rarely included in page level audits.

Track the rate by template family, because a single number hides the distribution. A site can post a respectable overall rate while its checkout templates, the ones with money and legal exposure attached, sit at twice the failure level of its content pages. The target size metric in Target Size Failure Rate: Measuring the Buttons People Cannot Tap showed the identical pattern: the aggregate flatters, the checkout tells the truth.

Fixing at the design system level

The durable fix is a focus style defined once in the design system, with enough contrast against every background the component ships on, and a rule that removing it requires an accessibility review rather than a designer's preference. Browser default outlines are ugly and functional. Custom indicators can be both better looking and more visible, but only if someone owns the comparison against adjacent colours, including the focus on focus state nobody screenshots.

Set the program target plainly: zero known focus visible failures on transactional templates, a declining rate elsewhere, reviewed each release. A metric with no target is a chart. This one earns its place by the company it predicts: when the rate falls, keyboard task completion rises in user testing, and the complaints stop arriving one at a time.

Frequently asked questions

What is focus visible failure rate?

The share of interactive component types on a site whose keyboard focus indicator is missing or not perceivable, counted at component level. It turns WCAG criterion 2.4.7, Focus Visible, from a per page audit finding into a trackable program metric you can compare across releases and templates.

Can automated tools measure focus visibility?

Partly. Automation catches outline removed with no replacement and some contrast problems, but it cannot reliably judge whether a subtle indicator is perceivable in real use. Use automation to find suspects, then verify with an actual keyboard tab pass through each template.

Why count components instead of pages?

Because one broken component repeats across hundreds of pages. Counting pages inflates the failure count and hides the single fix that resolves most of it. Component level counting describes the system you actually maintain and makes the rate comparable as the site grows.

What makes a good focus indicator?

Visible against every background the component appears on, not obscured by the element's own styling, and consistent across the site so keyboard users learn it once. The WCAG 2.2 criterion 2.4.13, Focus Appearance, at AAA, gives measurable guidance on size and contrast that good design systems borrow even when targeting AA.