Contrast Calculation for Radio Buttons and Checkboxes
This page explains how the tool decides whether a form control is visible enough, and where that decision is fragile. For the list of which controls are covered and how to read a report, see Active Elements Contrast.
What is being measured
This check is about the shape of the control itself, not about an icon inside it.
A checkbox is a little square. A radio button is a little circle. An empty text field is a rectangle. If the outline of that shape — or its fill — is too pale, the user cannot tell there is anything there to click.
A real example: a contact form with a Province field that has no placeholder text and a very light grey border (#c8c8c8) on white, measuring about 1.67:1. To many users it simply looks like blank page; they never realise there is a field to fill in.
How the measurement works
1. Gather the candidates. Native checkboxes, radio buttons and range sliders; anything marked up as a checkbox, radio, progress bar or slider; anything carrying a checked or unchecked state; empty text fields with no placeholder and no value; and dropdowns showing no visible text.
2. Throw out what does not count. Disabled controls are skipped — the standard explicitly exempts them. Anything hidden, transparent, pushed off-screen or clipped to nothing is skipped.
3. Find the actual little box. This is the tricky part. On modern sites the real checkbox is often hidden and a decorated element is what you actually see. So the tool first looks outward to find a visible container, then works inward looking for the small element that carries a visible border — "that is the square the user sees". Anything much larger than a checkbox is discarded, on the assumption that it cannot be the indicator.
4. Apply the browser-defaults gate. If the site's own stylesheet never touches the control's appearance, border, background or shadow, the control is skipped entirely. The reasoning: the browser drew this, it is not the site author's design decision. This is the single most important rule to understand about this check — see the limitations below.
5. Measure. The tool looks at the control plus a small margin around it and works out three colours: what is outside the control, the colour of its outline, and what is inside it. Picture pouring water in from the edges — the water stops at the outline, and what it could not reach is the inside.
- For an unchecked control the question is can you tell the control apart from the page? — comparing inside against outside, and outline against outside, keeping the better of the two.
- For a checked control the question is different: can you see the tick or dot? — comparing the mark against the background directly behind it.
6. Decide. Below 3:1 the control is reported. But before failing it, the tool gives the control several second chances: re-checking against the exact border colour from the stylesheet, then against the nearest containing element's real background colour. It only reports a failure when every one of those attempts stays under 3:1.
What it covers well
- Native checkboxes, radio buttons and sliders that the site has styled itself.
- Custom checkbox and radio implementations, including the common "hide the real input, decorate a sibling" pattern.
- Progress bars and sliders.
- Empty text fields, text areas and dropdowns — the Province case above.
- Both states: the empty box and whether the tick or dot inside a checked box is visible.
- It correctly exempts disabled controls and correctly ignores hidden ones.
Known limitations
- Anything the browser draws by default is skipped. A plain, unstyled checkbox or text field is never contrast-checked, even when the browser's own grey is genuinely hard to see. This is a deliberate product decision, not a bug — but it is a coverage gap, and it is the one to revisit if the team decides those cases should be reported.
- The gate asks "did the stylesheet mention it?", not "does it look default?" A control styled to look exactly like the browser default still gets checked, while a browser-default control gets a free pass. It is a rule of thumb, not a visual comparison.
- Fields with a placeholder or a pre-filled value are skipped, as are dropdowns showing an option label — the reasoning being that the visible text already tells the user the field exists. So a low-contrast border around a field that does have a placeholder is not reported.
- The size heuristic can pick the wrong element. Searching outward and then inward for "the little box" is a guess. It can land on a wrapper, a label, or the wrong decorated child — and then it measures the wrong colours. The upper size limit is worth double-checking for wide sliders and progress bars.
- "Has a visible border" is how the box is recognised. A control drawn with only a background colour, only a shadow, or a border on just one side may not be pinpointed correctly.
- Background images and gradients defeat it. When the tool hits a background image while looking for the real background colour, it gives up on an exact value and the verdict becomes less reliable.
- It leans towards passing. Because it takes the best of several comparisons and grants multiple second chances before failing, genuine borderline failures can slip through. Expect more missed issues than false alarms from this check.
- Only the state the page loads in. The tool does not click, hover or focus anything — hover and focus contrast are separate checks. A checkbox is evaluated as checked only if it already arrives checked.
- Only what exists and is visible right now — controls inside closed accordions, tabs or modals are not reached.
- Skips are silent. When a control cannot be located, or a colour cannot be determined, it is quietly skipped rather than reported as "could not check". So "no issues found" does not strictly mean "everything was checked".
Two points still to confirm
- Whether the rule that a progress bar is exempt when the same information is available as text is applied here. That text-based exemption was confirmed for dropdowns and text fields, but not for progress bars and sliders. Worth a targeted verification.
- Whether the upper size limit is in practice filtering out wide progress bars and sliders on real pages. The rule definitely exists; whether it bites depends on each page's actual dimensions.
WCAG reference
Success Criterion 1.4.11 Non-text Contrast (Level AA)