Non-text contrast: WCAG 1.4.11 explained with examples

Where can you type? Is a checkbox selected? Which button has keyboard focus? Readable text alone cannot answer all of these questions. Borders, check marks and icons also need to stand out from their surroundings.

This is non-text contrast: the difference in brightness between these visual cues and the colors immediately beside them. When that difference is too small, an input can blend into the page or a check mark can become hard to see. This makes controls especially difficult to use for people with low vision.

WCAG 1.4.11 requires at least 3:1 when a cue is needed to identify a control or its state. The ratio describes the brightness difference: 1:1 means no difference, while 3:1 meets the minimum requirement. Text has different requirements, explained in our color contrast guide.

Good and bad examples

These examples show three common contrast problems and a solution for each. They use fixed light or dark backgrounds so you can compare them regardless of the website theme.

An input that blends into the background

The field and its background are both white. The pale border is the only visible boundary, but it barely stands out. A darker border makes it easier to see where you can type.

A checkbox with a barely visible check mark

The checkbox itself is easy to see. Its white check mark almost disappears against the pale fill, making it hard to tell whether the box is selected. A dark check mark fixes this contrast problem.

A menu icon that fades on hover

Moving the mouse over the button makes the icon paler in the bad example. Its contrast drops below 3:1. The corrected version keeps enough contrast. Both examples keep their hover appearance visible so you can compare them.

Contrast results for the examples above

These values belong to the six examples shown above. Passed means the illustrated cue reaches at least 3:1 against the surface beside it. This assesses its non-text contrast; labels and keyboard operation need separate checks.

Which borders and icons need enough contrast?

The question is what you need to see to identify the control. For the white input above, it is the border. For the selected checkbox, it is the check mark. A visible checkbox border alone does not tell you whether it is selected.

Not every border needs a separate contrast check. A button may already be identifiable through its readable label. A line used only for decoration falls outside this requirement. W3C technique G209 explains this distinction.

Compare colors that touch: the check mark against the checkbox fill, or the input border against its surroundings. If several relevant colors meet, check each boundary. WCAG 1.4.11 exempts inactive controls and unmodified controls whose appearance is set by the browser.

Focus rings need visibility and contrast

The focus ring shows which element you are operating with the keyboard. WCAG 2.4.7 requires this focus to be visible. A custom focus ring also needs sufficient contrast against adjacent colors.

Use Tab to move through the page and check whether you can see focus everywhere. A ring may be clear on a white card and disappear against a colored background. If it has a gap around the control, check both sides: against the gap and against the outer background.

A visible focus ring does not tell you whether the field is identifiable without focus. Check its normal appearance too.

What an automated test detects

An automated test cannot replace these checks. The axe color-contrast rule checks text contrast. In our test with axe-core 4.10.3, it did not report the weak input borders, the barely visible check mark or the faded menu icon.

It did detect two text problems: the blue label of a selected tab in dark mode and low-contrast error text. The tab makes the distinction clear: its blue underline reaches 3.22:1, meeting the non-text contrast requirement. The label uses the same blue, but at 20px and medium weight it needs 4.5:1. It fails the text contrast requirement. Axe reports the text here.

A passing underline therefore tells you nothing about the label’s readability or the tab’s keyboard operation.

A scan can help you find text problems. You still need to check whether borders, check marks and icons remain identifiable. These findings apply to our examples and the tested axe version.

How to check your website

1. Go through the page. Can you identify inputs, checkboxes and icons? Also check what changes on hover, on selection and when using the keyboard.

2. Check light and dark views. Repeat the checks on the backgrounds where the controls actually appear.

3. Check the color pairs. Compare adjacent colors in the contrast checker. Necessary borders, icons and state indicators need at least 3:1.

4. Record the problem. Note the element, its state, the two colors and the result. After a change, check the label and keyboard focus again too.

The BIK non-text contrast test step describes manual testing in more detail, in German.

A clear task for your development team

Describe what is hard to see and when it happens. For the checkbox example, the task could read:

In dark mode, the white check mark is barely visible against the pale checkbox fill. Please change its color to reach at least 3:1 against the fill. Then check the selected and unselected checkbox in both views, as well as keyboard operation.

Find further checks in our accessible forms guide and website testing checklist. navable Audit supplements manual testing with automatically detectable findings.