Non-text contrast: the invisible button problem.

WCAG 1.4.11 requires interface components and meaningful graphics to carry at least 3:1 contrast against their surroundings — a measurement entirely separate from text contrast.

This is the clause most often missed in accessibility audits, and the reason it is missed is technically interesting: most of the common automated tools never test it. Because they do not test it, it does not appear in the report; because it is not in the report, the team does not know about it; and because the score is high, nobody goes looking.

This page first explains what the criterion says, then a concrete case that happened on this site — because abstract explanation does not work for this clause.

What the criterion says

1.4.11 “Non-text Contrast” sits at level AA and covers two things: user interface components and meaningful graphics. The threshold for both is 3:1.

1. Interface component — the visual information needed to understand what a component is and what state it is in. The border of a text field, the frame of a checkbox, the body of a toggle switch.
2. Meaningful graphic — visual elements that carry information. The line in a chart, the icon itself, a warning triangle.
3. Out of scope — pure decoration, disabled components, and logos. No threshold applies to these.
4. What is measured — not the component’s TEXT but its BOUNDARY or body. The two are entirely different measurements.

The last item is the essence of the criterion and the most confused point. The label on a button can measure 18:1 against its ground; if the button itself measures 1:1 against the page, 1.4.11 is violated. The label reads fine — but where the button begins and ends cannot be seen.

Why it matters becomes obvious on reflection: you cannot click into a form field without knowing where it is. For a low-vision user, an indistinct boundary is nearly the same as the field not existing. This is not an aesthetic nicety; it is a functional barrier.

The case on this site

A concrete record so the account does not stay abstract. In one audit round, this site’s accessibility picture looked like this: Lighthouse accessibility score 96, zero axe violations. A table that looked good by every measure.

At the same time, the only visual boundary of the text fields in the contact form — the site’s single conversion path — a thin underline, measured 1.29:1 against the ground. The threshold is 3:1. Where a field began and ended was unclear even for a fully sighted user.

A second defect surfaced in the same round: the text of a button on a dark band measured 18.15:1 against its ground — flawless. The button’s BOX measured 1.00:1 against the band. The button was, quite literally, invisible; only its label showed.

The score was high because the score was not asking that question.

Drilling to the root cause makes it plain: axe’s contrast rule measures only TEXT against its own background. In both cases the text was flawless, so the rule passed. 1.4.11 asks a different question — it concerns the component’s boundary — and no setting of axe was asking it.

The gap was not a tool error. The gap came from not checking WHICH QUESTION the tool asks.

The fix and the guard

The form field’s border was raised to 3.13:1. The value was deliberately kept just above the threshold: a darker line was possible but would have broken the form’s calm character. Accessibility worked here as a design constraint, not as a rule crushing the design.

The button’s box was made visible too. But the real lasting fix was neither: both measurements were bound to a test. The suite now reads real pixel values from the live page and verifies on every run that the form field boundary stays above 3:1.

This distinction is critical. Fixing a defect removes it once; adding a guard prevents it from returning. Most accessibility fixes are silently undone in later deployments — a new component, a new color, a new band. With a guard, the undoing shows the moment it happens.

How to look for it on your own site

Finding 1.4.11 defects is hard with automated tools and easy by hand. The method is simple and takes ten minutes.

1. Open the form and do NOT look at the fields — shrink the screen, squint, or lower the screen brightness. Can you still see where the fields are?
2. Separate every button from its ground — measure the contrast between the button’s box and the ground behind it. The box, not the label.
3. Check the checkboxes and radio buttons — custom-styled ones break most often; browser defaults are usually conformant.
4. Classify the icons — an icon carrying information on its own (no text beside it) is a meaningful graphic and needs 3:1.
5. Measure the charts and tables — every series in a line chart must be distinguishable against the background and against each other.
6. Do not forget the focus ring — the focus indicator is an interface component too and needs 3:1.

The last item is especially insidious. A focus ring left at the default blue easily falls below the threshold on a dark ground. And this defect affects only keyboard users — nobody testing with a mouse ever sees it.

The general lesson of this clause fits one sentence: the most dangerous state in an accessibility audit is not a defect going unfound but a defect going UNSOUGHT. A green report is only the answer to the questions that were asked — and knowing which questions were not asked is the auditor’s responsibility.

Why automated tools skip this clause

There is a technical reason this clause almost never appears in automated audits, and knowing it helps decide how much to trust a tool’s report. Measuring text contrast is algorithmically easy: there is a text node, its color is known, the ground behind it can be computed, the ratio follows. Measuring a component boundary is a different problem entirely, because the tool first has to answer “which part is this component’s boundary” — and that question requires visual judgment.

A text field’s boundary can be an underline, a four-sided frame, a soft shadow, or merely a ground color different from the page. All four are valid design solutions, and for a tool to decide which counts as the “boundary” it would have to see the page the way a human does. Today’s tools cannot, so they either never test the criterion or test it only on elements with an explicitly defined border property.

As a result, 1.4.11 is the most expensive member of the set of criteria automated auditing does not cover: when broken it produces a real user barrier, yet it shows in no report. It must therefore be sought by hand — and as long as it is not sought, it is assumed not to exist.

Checklist: everything that has a boundary

When searching by hand, the scope is hard to keep in mind because the criterion speaks in an abstract term like “interface component.” In practice the list below covers nearly all the situations where 1.4.11 applies on real sites, and it can be walked in a ten-minute sweep.

1. Text fields and text boxes — whatever the boundary is (line, frame, ground difference), 3:1.
2. Checkboxes and radio buttons — especially custom-styled ones; browser defaults are usually conformant.
3. Toggle switches — both the body and the mark showing the on/off state.
4. Ghost buttons — the most often broken pattern; a button existing only as text has an invisible box.
5. Dropdown arrows and date picker icons — they carry information; they are not decorative.
6. Progress bars and sliders — both the track and the handle.
7. Series in charts — every series must be distinguishable against the ground and against each other; a color difference alone is not enough.
8. The focus ring itself — it too is an interface component and needs 3:1.

The last item on the list is the most insidious and the subject of its own article: because the focus indicator affects only keyboard users, nobody testing with a mouse ever notices its contrast. On a dark ground the default blue ring easily drops below the threshold, and the defect can live for months.

The real lesson of the case this page tells is not the contrast value but the method. The defect was found not by a tool’s report but by asking “which question does this tool ask.” The most dangerous state in an accessibility audit is not the defect that cannot be found but the defect that is never sought.