UI Contrast: Check Labels, Boundaries and States Separately

A component rarely has only one contrast relationship. An input can contain a label, typed value, hint, boundary and focus indicator. A button has a label, fill, surrounding surface and state cues. Break the component into these parts before deciding what to measure.

Example: a text input on a white form

If this border is needed to identify the input, evaluate it as that visual cue rather than applying the normal-text threshold to the border. Non-text contrast generally requires 3:1 for visual information needed to identify controls and states. Not every decorative boundary is required to meet it; the role and surrounding information matter.

Now inspect the typed value and helper message independently. Even if the border meets its requirement, the helper text can still fail. Conversely, a strong label does not resolve an invisible required input boundary.

Example: a filled button

Next inspect how the button is identified on the page surface. A border is not universally required when the control can be identified without it. If you add a focus ring, check it where it appears: outside the button, inside the button, or across both edges. The relevant adjacent colors depend on that placement.

Compare states with their surroundings

For a hover style, recheck the label against the new fill. For a selected checkbox, check the mark against the box. You do not automatically need 3:1 between the default and hover colors just because they are different states; they may never be adjacent. You do need the meaningful information to remain identifiable in the state being displayed.

Keep a component test sheet

• •Input default: value/surface, hint/surface and required boundary/adjacent surface.
• •Input focus: visible focus cue and each relevant adjacent surface.
• •Button default and hover: label/fill in each state.
• •Selected and error states: readable labels plus a cue that does not rely solely on hue.

Disabled controls have specific exceptions in the criteria; treat these as scoped requirements, not a reason to make all secondary content faint. A helper message, read-only value or low-priority action is not necessarily an inactive control.

Load any of these pairs in the contrast checker and choose the target for the specific check. Its text pass labels are not a verdict on the whole component.

Finish with keyboard and visual inspection in the rendered interface. Contrast arithmetic cannot confirm that focus is present, that the control has an accessible name, or that the error message is associated with its field.