Focus indicator does not meet minimum size or contrast

What is this issue?

An interactive element has a focus indicator that renders and is unobstructed, but falls short of the specific minimum size and contrast thresholds 2.4.13 Focus Appearance introduces: an area equivalent to at least a solid 2-pixel-thick border around the element’s perimeter, and a contrast ratio of at least 3:1 between the indicator’s colors in its focused and unfocused states, measured against the colors adjacent to it.

A 1px dotted outline in a color close to the page’s background technically satisfies 2.4.7 Focus Visible (something changes when the element receives focus) while still failing this stricter criterion, because “something visible happened” and “something clearly, reliably visible happened” are different bars. This rule tests the second, higher bar specifically.

Why does this matter?

2.4.7 Focus Visible only requires that some indicator exist; it says nothing about how good that indicator has to be. In practice, that gap let a generation of subtle, easy-to-miss focus styles (thin single-pixel outlines, faint color shifts) technically satisfy the letter of the older criterion while still being genuinely hard to see for anyone with reduced visual acuity, screen glare, or simply a fast-moving Tab sequence to track.

2.4.13 closes that gap with concrete, measurable thresholds instead of a vague “must be visible” standard, specifically because subjective visibility judgments were inconsistent between designers, testers, and real users in practice. A focus ring that one designer considers clearly visible on their high-contrast monitor in ideal lighting can be nearly invisible to a low-vision user on a different display, which is exactly the gap a concrete minimum size and contrast threshold exists to close.

Who is affected?

• Low vision users: need a focus indicator with enough area and contrast to register clearly against whatever they’re viewing, especially at higher zoom levels or with reduced visual acuity where a subtle indicator effectively disappears.
• Keyboard users: even without a diagnosed vision condition, tracking a thin or low-contrast indicator across a fast Tab sequence is genuinely harder than tracking a bold, high-contrast one, slowing down navigation for anyone relying on it.
• Motor impairments: users navigating via switch device or head pointer, who may be tabbing more deliberately and slowly than a typical keyboard user, benefit disproportionately from a clear, unambiguous indicator at every stop along the way.

What users experience

Nadia has low vision and uses a combination of screen magnification and keyboard navigation to browse. On a SaaS dashboard, every interactive element uses a custom :focus-visible style of outline: 1px dotted #aaaaaa, a deliberate design choice to keep the interface visually “clean.” At her usual zoom level, the thin dotted line blends into the light gray background almost completely. She tabs through a settings form and can tell focus is moving somewhere, because the page occasionally scrolls, but can’t reliably pinpoint which field is active without zooming in further and scanning carefully, adding a verification step to every single field she fills in.

How do I fix it?

Use a solid outline at least 2 CSS pixels thick, ideally 3px for extra margin, as your default :focus-visible style. This works because a solid, sufficiently thick outline is the most reliable way to clear the minimum-area threshold without needing to calculate exact coverage for a non-outline indicator style, and it degrades gracefully across zoom levels and display quality.

Pair that with a color carrying at least 3:1 contrast against both the component’s background and the page background behind it, since the indicator needs to read clearly in both states. outline-offset helps here too: pushing the outline a couple of pixels away from the element’s own edge keeps it from blending into a similarly colored border or background the element itself might have, improving effective contrast without changing the outline’s actual color value.

Code Examples

:focus-visible {
  outline: 1px dotted #aaaaaa;
}

:focus-visible {
  outline: 3px solid #0052cc;
  outline-offset: 2px;
}

/* Component on a dark background needs its own contrasting color */
.dark-bg :focus-visible {
  outline: 3px solid #ffffff;
  outline-offset: 2px;
}

Increasing the outline to a solid 3px line clears the minimum-area threshold with margin to spare, and switching to a saturated blue against a light background (with a white variant defined for dark backgrounds) ensures the 3:1 contrast requirement holds regardless of which surface the focused element sits on; a single fixed color rarely works everywhere in a design system with both light and dark surfaces.

Common Mistakes

Mistake: “We have a focus style, so 2.4.7 and 2.4.13 are both automatically satisfied.” 2.4.7 only requires an indicator exists; 2.4.13 requires it to clear specific size and contrast minimums on top of that. A page can have a focus style on every interactive element and still fail 2.4.13 if that style is too thin, too subtle, or too low-contrast, which is precisely why RedFlag documents them as two separate checks.

Mistake: “A subtle focus style is more visually polished, so it’s worth the accessibility tradeoff.” There’s no inherent tradeoff to accept: a solid, higher-contrast outline can be designed to fit a polished visual system just as well as a subtle one; the two goals aren’t in tension by necessity. Treating visual restraint and accessible visibility as opposing forces usually reflects a design choice made without exploring bolder options, not an unavoidable constraint.

Mistake: “We tested contrast against the page’s main background color, so we’re covered.” 2.4.13’s 3:1 requirement is measured against the colors immediately adjacent to the indicator, in both focused and unfocused states, which can differ from the page’s overall background if the element sits inside a card, a colored section, or another nested surface with its own background color.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. RedFlag’s own coverage model records this criterion’s evidence as docs_only; there is no outline-thickness or contrast-ratio measurement for focus indicators anywhere in RedFlag’s detection code today. The related guided manual walkthrough behind Focused element has no visible focus indicator only judges whether an indicator is visible at all; it does not measure against this criterion’s specific 2-pixel-area and 3:1-contrast thresholds.

False negative: every occurrence of an under-sized or low-contrast focus indicator passes every RedFlag scan silently today, since nothing automatically measures against these thresholds. False positive: not applicable, since nothing is ever automatically flagged. Manual step: measure your default and component-specific focus styles against the 2-pixel-area and 3:1-contrast minimums directly: a browser’s DevTools computed-style panel and a contrast-checking tool both help confirm the numbers rather than relying on a visual judgment call alone.

Manual Testing

1. Open the page in Chrome or Firefox and Tab to each distinct type of interactive element (buttons, links, form fields, custom controls).
2. For each one, inspect the computed outline (or equivalent) style in DevTools and note its thickness.
3. Confirm the visible indicator covers an area at least equivalent to a solid 2px border around the element’s full perimeter.
4. Use a contrast-checking tool to confirm at least 3:1 contrast between the indicator’s color and the colors immediately adjacent to it, in both the focused and unfocused states.
5. Repeat for any component with a non-default background (cards, dark-mode sections, colored panels), since contrast against those surfaces can differ from the page’s main background.

Related WCAG Success Criteria

2.4.13 Focus Appearance: A keyboard focus indicator must meet minimum area and contrast thresholds once it exists. This rule maps directly to that requirement: an indicator that exists but falls short of the concrete size or contrast minimums fails 2.4.13 even while satisfying the more basic 2.4.7 Focus Visible.

1.4.11 Non-text Contrast: Visual information required to identify user interface components must have at least 3:1 contrast against adjacent colors. Focus indicators are one specific application of this broader principle, which is why the two criteria’s contrast math is closely related even though 2.4.13 is the more directly applicable citation for this rule.

Related Issues

Focused element has no visible focus indicator is this trio’s foundational check under 2.4.7: whether an indicator exists at all, a lower bar this rule’s 2.4.13 requirement builds on top of.

Focused element is hidden behind a sticky header or footer is the second page in the trio, covering 2.4.11 Focus Not Obscured (Minimum): a well-designed indicator that clears this rule’s size and contrast bar but still gets visually covered by page layout.

Text does not have enough colour contrast shares the same underlying contrast-math concern as this rule, applied to text readability rather than a focus indicator’s visibility.

References

• W3C Understanding 2.4.13: Focus Appearance
• W3C Understanding 1.4.11: Non-text Contrast
• MDN: outline-offset