Contrast is not only about text

Teams get diligent about text contrast and then ship an input whose border is barely visible, a focus ring nobody can see, and a chart whose series are told apart only by pale colours. All three have requirements, and all three are missed constantly.

The rule

WCAG 1.4.11 asks for 3:1 against adjacent colours for two categories: the visual information needed to identify a user interface component and its state, and the parts of a graphic required to understand the content.

The usual failures

Focus indicators deserve their own attention

A focus ring is the only thing telling a keyboard user where they are. It must contrast with the background and with the component it surrounds — which is why a ring in your brand colour often fails on a page that already uses that colour.

/* a ring that works on light and dark surfaces */
:where(a, button, input, select, textarea):focus-visible {
  outline: 2px solid var(--focus);
  outline-offset: 2px;
}

:root { --focus: oklch(0.45 0.20 264); }
[data-theme="dark"] { --focus: oklch(0.78 0.16 264); }

The offset matters. A ring drawn tight against a button of similar colour can meet the contrast requirement on paper and still be hard to see; a two-pixel gap puts it against the page background instead.

Charts are the hardest case

A chart needs adjacent series distinguishable from each other, not just from the background. With more than about five series, colour alone stops being sufficient regardless of contrast, and you need direct labels, dash patterns or markers.

A five-minute audit

1. Tab through a page and watch the focus ring. If you lose it anywhere, that is a failure.
2. Measure one input border against its background.
3. Measure one icon-only button against its background.
4. Put a toggle in each state side by side and check they differ by more than a tint.
5. Screenshot a chart, desaturate it, and see whether the series are still separable.

Building the requirement into components

The reason non-text contrast fails so consistently is that it is checked at the end, on a finished page, when changing a border colour means touching a dozen components. Encoding it in the tokens instead makes the correct value the default.

:root {
  /* measured at 3:1 against --surface, not chosen by eye */
  --border-strong: oklch(0.62 0.01 264);
  --focus:         oklch(0.45 0.20 264);
}

input, select, textarea { border: 1px solid var(--border-strong); }

:where(a, button, input, select, textarea):focus-visible {
  outline: 2px solid var(--focus);
  outline-offset: 2px;
}

What automated tools will not catch

Automated checkers are good at text contrast and largely blind to this criterion, because deciding whether a graphic is required to understand the content is a judgement call. Expect to find these by hand — which is why the five-minute audit above is worth running before each release rather than hoping a tool will flag it.

States need to differ from each other

A point that the 3:1 figure obscures: the requirement is about identifying a component and its state, which means the states have to be distinguishable from one another, not only from the background. A toggle whose on and off positions both pass against the page but differ from each other by a faint tint has not met the intent.

• Checked and unchecked checkboxes should differ by more than fill colour — a tick mark does the work.
• Selected and unselected tabs need a border, weight change or indicator, not only a colour shift.
• Toggle on and off benefit from the handle position, which is a non-colour signal already.
• Disabled should be visibly inactive without being invisible.

Where the requirement does not apply

It is worth being precise about the exemptions, because over-applying the rule produces heavy, cluttered interfaces and makes teams dismiss the criterion entirely.

The pattern in that table is consistent: if removing the element would lose information the user needs, it has to be perceivable. If it would only look plainer, it does not.