Check non-text contrast under WCAG 1.4.11: input borders, icons, focus rings and state indicators need 3:1 against adjacent colors. Pick the component and background colors, see a live input-and-icon mock, and get a straight pass/fail with the reasoning.
Settings
Generated locally in your browser — your settings and results never leave this page.
The other contrast rule
Text contrast (1.4.3) has a famous rule; interface contrast (1.4.11) has an ignored one. Since WCAG 2.1, the visual information that identifies components and their states — input boundaries, meaningful icons, focus rings, checked-state marks — must hold 3:1 against adjacent colors. It is the rule that outlaws the beloved barely-there input border, and the least-audited requirement in modern web design. This checker gives it a dedicated instrument.
What counts, what does not
In scope: anything a user must perceive to find or operate a control — the border that says “type here”, the icon that is the button, the ring that answers “where is my focus?”, the mark that distinguishes checked from not. Out of scope: decorations whose disappearance loses nothing, disabled controls (explicitly exempt), and boundaries made redundant by another 3:1 mechanism — a filled input whose fill contrasts with the page needs no passing border. The kind selector tunes the verdict text to these distinctions.
The gray border hall of shame
The modern-framework default border palette — #e5e7eb, #e2e8f0, #eeeeee on white — measures 1.1–1.3:1: functionally invisible to low-vision users, who report exactly that (“forms with no fields”). The passing world starts near #949494 on white. The live mock renders your actual border on your actual background beside a meaning-bearing icon, so the difference between fashionable and findable is visible in the tool, before support tickets make it visible in production.
Focus indicators, the stakes-raiser
Keyboard users navigate by the focus ring; an invisible ring is an unusable page. 3:1 against adjacent colors is the floor (and WCAG 2.2’s 2.4.13 adds size guidance) — but rings border two surfaces, the component and the page, and must clear the bar against both. Check both pairings here, and when a single ring color cannot satisfy both, the two-tone ring (light inner, dark outer) is the standard escape — each tone handling one adjacency.
The placeholder-text boundary case
Placeholder text sits exactly on this rule’s edge and deserves its own note: as text, placeholders technically owe 4.5:1 under 1.4.3 — yet the design convention of faint placeholders persists because they must not impersonate entered values. The resolution most accessible designs adopt: keep placeholders as non-essential hints (never the field’s only label), style them just past 4.5:1, and move critical information to a real label with full contrast. When a design insists on fainter placeholders, floating labels — which migrate the hint to a compliant position on focus — are the pattern that satisfies both masters.
How to use the UI Component Contrast Checker
- Pick the component color and the background it sits on.
- Say what the component is – border, icon, focus ring or state indicator.
- Read the 3:1 verdict with a live input-and-icon mock.
Frequently asked questions
What does WCAG 1.4.11 non-text contrast actually require?
3:1 against adjacent colors for visual information required to identify UI components and their states, and for parts of graphics needed to understand content. Input borders, icons that convey meaning, focus indicators, checkbox states – all in scope. Pure decoration is exempt.
Why 3:1 instead of the 4.5:1 text needs?
Components are bigger and simpler than glyphs – recognizing a rectangle needs less contrast than reading an 8px letterform. The thresholds encode that: large shapes 3:1, fine text strokes 4.5:1.
Is my light-gray input border really an accessibility failure?
The beloved #e5e7eb-on-white border measures about 1.2:1 – far below 3:1, effectively invisible to low-vision users. It is among the most common failures on the modern web. This checker flags it; a #767676-class border passes with the same design language.
Does a filled input need a passing border at all?
If the fill itself contrasts 3:1 with the page, the boundary is conveyed by the fill and the border can be decorative. The rule targets the information "here is a field" – any 3:1 mechanism satisfies it: border, fill, or strong shadow.
How do focus indicators fit this rule?
A focus ring is precisely "visual information identifying a state", so 3:1 against adjacent colors is the floor (WCAG 2.2 adds size/area guidance in 2.4.13). Check the ring color against both the component and the page – it borders both.
What about disabled controls?
Explicitly exempt – disabled states may be low-contrast by design. The trap is inheriting a "disabled-looking" gray for enabled placeholder or secondary controls; if a user must find it, it is not exempt.
Which icon colors are in scope – all icons?
Icons that carry information a user needs (the delete trash-can, the status dot, the menu burger): 3:1 required. A purely decorative flourish beside a labeled button: exempt. The question to ask is "if this icon vanished, would meaning be lost?" – yes means measure it here.
