Icons, borders and state indicators must meet a contrast threshold too

What it is

Readable body copy does not mean the icon beside it, the input edge, or the switch thumb is findable. Pixels that identify a control or a state need a contrast threshold against the adjacent colour. That requirement is non-text contrast. It is about shape and boundary, not type size.

A common miss: the text is dark enough, so the UI is assumed to pass. A pale check on a white card, a progress arc at 8% opacity over a photo — the letters survive, the graphic dissolves.

Why it happens

Reading letters is a resolution problem: small strokes need high contrast or they smear. Identifying a control is an edge-detection problem: boxes, dots, ticks and slider troughs are larger, simpler shapes, so the working criterion is typically 3:1, not the stricter ratio used for body text. The comparison is with the adjacent colour, not the page’s canonical background — an icon sitting on a grey card is judged against that card, not against the white canvas outside it.

State indicators are graphics too. A switch track and thumb that differ only by two close blues will not tell a low-vision user on from off. If a text label already names the state, a failed graphic may not hide the function; if the graphic is the only cue, the failure is a loss of perceivability.

Studying it

Sample the control’s edge against neighbouring pixels, not the heading text. WCAG 2.x places user-interface components and graphical objects needed to understand content under the same 3:1 bar; APCA can be used as a research check on perceived lightness, but conformance claims still usually cite the ratio.

Independent variables: graphic-to-adjacent contrast, stroke width, whether the graphic is the sole state cue. Dependent variables: correct detection of the control, its current state, and the icon’s meaning; miss rate.

Walk primary paths under low-vision simulation (blur, contrast compression) and log places where “the words remain, the control is gone.” Automated rules catch solid-on-solid; they miss the actual edge of a thin anti-aliased stroke.

Where it stops holding

Decorative rules and textures that do no identification work are out of scope. Disabled states are often allowed lower contrast, because looking unavailable is the point — provided disabledness is not the only “you cannot use this” message. Colour patches in photos, illustrations, or charts that already have axes and numeric labels can sit below 3:1; patches that are the encoding cannot. A 1 CSS-pixel stroke is interpolated on high-density screens; a lab ratio is not the retinal ratio.

Applying it

• Give icons, switches, radio circles, progress marks, required asterisks — anything that speaks by shape — at least 3:1 against the adjacent colour. Do not threshold body text only.
• When a control sits on a tinted card, a photo, or a gradient, the neighbour is the colour the edge actually touches, not the artboard white.
• If fill colour is the only state distinction, add position, a tick, or text so a failed graphic still has a fallback channel.
• How to check: stop reading the words. Eyedrop the icon outline and the pixels hard against it. Every “text clear, graphic gone” point is a fail.

Related

• Same group: J2.10.2 Unchecked checkbox and input borders are the most often-missed low-contrast elements · J2.10.3 Visual information that changes on hover or focus must keep the same contrast · J2.10.4 Contrast cannot be signed off on mockups; it must be verified on rendered pixels
• Nearby: J2.01 Text Contrast · J2.03 Color is Not the Only Cue · J2.06 Focus Visibility
• Search terms: non-text contrast · UI component contrast · 3:1 graphical object