Active Elements Contrast
This check scans a page for interactive form controls — radio buttons, checkboxes, text fields, dropdowns, sliders, progress bars — and verifies that each one is visually distinguishable from its background. Anything measuring below 3:1 is reported.
For the detail of how the contrast of these controls is worked out and where that calculation is fragile, see Contrast Calculation for Radio Buttons and Checkboxes.
Why it matters
Users with low vision, colour vision deficiencies, or anyone working in bright light rely on contrast to locate and operate form controls. A checkbox that blends into a white background is effectively invisible to them: they cannot tell whether a field exists, let alone whether it is ticked.
What the tool checks
Native controls
| Control | When it is included |
|---|---|
input[type="radio"] | Always; both checked and unchecked states |
input[type="checkbox"] | Always; both checked and unchecked states |
input[type="range"] | Always — the slider track and thumb |
input[type="text"] | Only when the field has no placeholder and no pre-filled value |
input[type="email"] | Only when empty |
input[type="password"] | Only when empty |
textarea | Only when empty |
select | Only when no selected-option text is visible |
Custom controls
Components built out of other elements are included when they carry the matching role: a custom radio, a custom checkbox, a progress indicator, a slider, or any element that exposes a checked / unchecked state.
What it does not cover
| Excluded | Reason |
|---|---|
| Controls styled only by the browser | The browser vendor is responsible for the contrast of an unstyled native control, not the site author |
| Hidden or off-screen controls | Anything inside a collapsed accordion, a hidden tab or an unopened modal |
| Disabled or inactive controls | WCAG explicitly exempts them |
| Text inside controls | Placeholder text and labels belong to the text contrast check |
| Focus indicators | Covered by the Focus Visible check |
| Icons and graphics inside controls | Covered by the Non-text Contrast check |
| Controls behind a login | The tool has to be pointed at the signed-in state first |
| Controls that appear only after an interaction | The tool measures the page as it loads |
What the report says
Each failing control is a separate entry, naming the element, the two colours, the measured ratio and a suggested fix.
Title: The border of the
<input type="radio">control fails to achieve sufficient contrast with the backgroundActual result: The light gray (#d1d5db) of the "radio" control border fails color contrast against the white (#ffffff) background with a ratio of 1.61:1.
How to fix it: Change the border color from #d1d5db to at least #767676 to achieve a 3:1 contrast ratio against #ffffff.
The three failure patterns
The border fails — the control's outline does not stand out from the page. By far the most common; typically a light-grey border on a white background.
The background fails — the control's fill does not stand out from the area around it.
The checked state fails — the tick, dot or fill that shows the control is selected does not stand out from the inside of the control.
Overall outcomes
| Outcome | What it means |
|---|---|
| Pass | Every control found met the 3:1 minimum |
| Fail | At least one control fell below it |
| Undetermined | No controls were discovered, so the check could not run |
Reading "approx." in a report
When the report says the white (approx.) (#ffffff) background, the background colour was estimated from the nearest containing element that has a solid background. Reliable in most cases, but it can be off on pages with complex layering or blurred backdrops.
Example: from report to fix
A registration form reports six failures, all with the same cause:
/* Before — fails at 1.61:1 against #ffffff */
.form-radio {
border: 2px solid #d1d5db;
}
/* After — passes at 4.62:1 against #ffffff */
.form-radio {
border: 2px solid #6b7280;
}Re-running the check confirms the fix.
Common false positives and false negatives
A partially styled native control is reported. The site overrides part of a control's appearance but leaves the border alone, so the tool treats it as author-styled and measures a failing contrast. Either set an explicit border colour that passes 3:1, or remove the partial override so the browser owns the whole appearance.
A control on a gradient is reported inconsistently. The tool samples one point of the gradient. A control can pass over one part of it and fail over another; only the sampled point appears in the report. Check the control across the full gradient and pick a border colour that passes everywhere.
Controls in hidden states are missed. Collapsed accordions, hidden tabs and closed modals are not scanned. Navigate to the relevant state before running the check.
The whole page comes back Undetermined. Every control is using purely browser-default styling, so all of them were skipped. This is correct behaviour, but unexpected. Adding explicit border or background colours brings them under the check — and under the site's own control.
Dynamically added controls are missed. Controls that appear after a button click or a "Load More" are not discovered. There is no built-in support for this; navigate to the state manually first.
A note on coverage
An earlier version of this check covered fewer control types. Progress bars, custom sliders, elements carrying a checked state, and empty dropdowns were added later. If you see more issues than before on the same page, that is broader coverage, not a regression.
WCAG reference
Success Criterion 1.4.11 Non-text Contrast (Level AA)
"The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s): User Interface Components — Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author."