Contrast of states must be rechecked on every container background

What it is

The same button will sit on a white card, a photo banner, a colored alert, a translucent overlay. Default / hover / disabled tuned against an artboard white will collapse on those containers. State contrast has to be rechecked against the surface it sits on, not against absolute swatches inside the component. The same token can vanish on another fill, or become a second primary.

Why it happens

Contrast is the difference from neighboring pixels, not from the mock’s artboard. A translucent button lets a photo highlight through; a darker hover on that highlight can still out-shout nearby type. An outlined secondary on a same-hue banner loses its outline and leaves type that looks like a link. Frosted glass, or white type on a photo, will swallow the small lightness step of pressed in the photo’s detail. Containers also bring their own theme: a danger banner already red, plus a red filled Delete, smears primary and danger together. A library guarantees “holds on the agreed surface.” Off that surface, the five relative steps have to be measured again.

Studying it

Place the same component on at least four containers: default card, dark photo, brand banner, modal overlay. Measure contrast per state and force “clickable or not / loading or not.”

Independent variables: container kind, translucency, spatial frequency of the photo. Dependent variables: contrast falling below discrimination, forced-choice errors, container texture misread as pressed.

A static primary is not enough. Hover and disabled are the states that vanish first on busy fills; they must be conditions.

Where it stops holding

An opaque, self-filled primary is less sensitive to the container, but disabled grey can still collide with container grey. Video and animated backgrounds change every frame; a static check is not enough—use a worst frame, or give the button a stable underlay. Shadow dies on a dark container, so a secondary that used shadow for hierarchy fails; switch to a stroke rather than blaming the container.

Applying it

• List the containers the button will actually sit on and shoot five states on each; “should be similar” is not a pass.
• On photos and video, put an opaque well under translucent or outlined buttons before painting states.
• Do not reuse a filled button of the same hue as a colored banner.
• Verify by walking hover, pressed, and disabled on the real page, not the component artboard. If a state can be told apart from the texture only by imagination, contrast was not rechecked on that container.

Related

• Within the group: E1.11.1 The five states must be checked per theme, not inverted from light · E1.11.2 A disabled icon button must fade both glyph and type · E1.11.4 Hover and disabled must not appear together
• Adjacent: E1.02 Button states · J2.10 Non-text contrast · F3.01 What makes visual weight
• Search terms: surface contrast · button on image · container background