What is a focus indicator — and why does WCAG regulate it?
When a user navigates a website using a keyboard, they need to know where they are on the page at all times. The focus indicator is the visual signal that answers that question: the outline, highlight, or state change that appears on the element currently receiving keyboard focus.
WCAG Success Criterion 1.4.11 (Non-text Contrast) requires that the visual presentation of UI components, including focus and hover indicators, has a contrast ratio of at least 3:1 against adjacent colors.
Without a sufficient focus indicator:
Keyboard-only users lose their place on the page.
Users with low vision cannot perceive the current focus state.
The product fails a Level AA audit, the standard required by the EAA, ADA, and EN 301 549.
Below are three real cases from accessibility audits, extracted from a structured issue bank. No simulated data. No approximations.
Case 1 — Login page: Dropdown focused/hovered option
Component: "Tipo de documento" dropdown — focused and hovered option state
Audit type: Color Contrast · Priority: High
What was found:
When the dropdown expanded and the user hovered or focused an option, the selected state was communicated only through a light grey background. There was no outline or other indicator with sufficient contrast.
The CSS driving the problem:
.css-1kwd9xn-option {
background-color: rgb(241, 244, 244); /* #F1F4F4 */
color: rgb(0, 43, 69);
font-size: 14px;
font-weight: normal;
}
A ratio of 1.1:1 means the focused state is virtually indistinguishable from the default state. For a user with low vision navigating with a keyboard, the dropdown is effectively unusable.
The fix:
Replace the near-white background with a grey that achieves the required 3:1 threshold against the white page background.
css/* Before /
.css-1kwd9xn-option {
background-color: rgb(241, 244, 244); / ratio 1.1:1 — FAIL */
}
/* After /
.css-1kwd9xn-option:hover,
.css-1kwd9xn-option:focus {
background-color: #939393; / ratio 3.0:1 against #FFFFFF — PASS */
}
Case 2 — Login page: Password digit field borders
Component: Input field boundaries — digit fields for password entry
Audit type: Color Contrast · Priority: Medium
What was found:
The password entry screen used a series of individual digit input fields. Each field had only a bottom border as its visible boundary — the indicator that communicates "this is an input". That border failed the 3:1 contrast requirement against the white background.
WCAG 1.4.11 applies not only to focus rings but to any visual indicator that communicates the presence or boundary of an interactive component. A field border that a user cannot see means they cannot locate the input.
The fix:
Use a darker grey for the border that maintains the visual style while meeting the threshold.
css/* Before /
.password-digit-field {
border-bottom: 1px solid #CCD5DA; / ratio 1.48:1 — FAIL */
}
/* After /
.password-digit-field {
border-bottom: 1px solid #8094A3; / ratio 3.14:1 — PASS */
}
Case 3 — Account page: Radio button borders
Component: Radio button visual boundaries — payment method selection
Audit type: Color Contrast · Priority: Low
What was found:
A payment method selection screen presented a group of radio buttons for choosing between credit cards. The unchecked radio buttons used a light grey border to indicate their boundary. That border failed 3:1 against the white background.
When radio button borders are invisible, users with low vision cannot detect that a selectable option is present. This is a form usability failure, not just an aesthetic one: invisible controls block task completion.
The fix:
css/* Before /
.sc-radio-field-label:before {
border: 0.0625rem solid #C2CFD6; / ratio 1.59:1 — FAIL */
}
/* After /
.sc-radio-field-label:before {
border: 0.0625rem solid #949494; / ratio 3.03:1 — PASS */
}
What these three cases have in common
All three failures share the same root cause: grey UI elements on white backgrounds, where the grey is not dark enough to reach 3:1.
This pattern is extremely common in design systems that prioritize subtle, minimal aesthetics. The visual result feels clean. The accessibility result is that a significant portion of users cannot perceive the interface.
None of these fixes required redesigning the component. Each required changing one CSS color value.
Top comments (0)