Color Theory & Contrast

The plain-language idea

Color communicates meaning and hierarchy — but whether text is actually readable isn't a matter of taste. It's a number: the contrast ratio between a foreground and background color, computed from their relative luminance (how much light each color reflects, weighted the way human eyes perceive brightness — green reads much brighter than blue at the same numeric value).

The ratio ranges from 1:1 (identical colors, invisible) to 21:1 (pure black on pure white). WCAG sets minimum ratios for different text: 4.5:1 for normal body text, 3:1 for large text (24px+, or 18.66px+ bold) and for meaningful UI components/icons. Below the threshold, text doesn't just look "a bit dim" — it fails for a real, definable slice of your users: anyone with low vision, anyone on a washed-out monitor, anyone in bright sunlight.

See it in a real thing: a bug that actually shipped

This isn't a hypothetical. This exact platform had this exact bug:

// A chat-bubble role label, meant to look "de-emphasized" next to the message
<span style={{ opacity: 0.75 }}>You</span>

White text (#ffffff) on this app's jade accent background computes to a clean 4.92:1 — comfortably above the 4.5:1 bar. But opacity: 0.75 doesn't just make the text fainter — it blends the whole element 25% toward whatever's behind it. Because the label's own backdrop is that same accent color, the rendered result is white blended toward green: #bfe0d4. Re-measured against the same background, that's 3.44:1 — a real, measured failure, not a rounding error.

A white label at full opacity on this app's own accent green — a flat 4.92:1. Comfortably above the 4.5:1 bar.

BackNext

The token was never wrong. opacity silently changed what actually got painted to the screen, and nothing about the code looked broken — no red squiggly line, no visual "that's clearly too faint" moment on a bright monitor. It took an automated contrast scan to catch it.

What people usually miss

Watch out

• The size threshold changes the bar, not just the number. Large text (≥24px, or ≥18.66px if bold) only needs 3:1. This is precisely because larger glyphs are more legible at lower contrast — it's not an arbitrary carve-out, and mixing up which bar applies to which text is a common interview stumble.
• Non-text UI still has a bar. WCAG 1.4.11 requires 3:1 for meaningful graphical objects and interactive-component boundaries (an icon-only button's icon, a focus ring, an input's border) — "it's not text" doesn't mean "no requirement."
• AA and AAA are different targets. AA (4.5:1 / 3:1) is the bar almost every product targets and the one most interview questions mean by default. AAA (7:1 / 4.5:1) is stricter and mostly reserved for content specifically aimed at low-vision users — conflating the two is a tell that someone has memorized "the number" without understanding there are two.
• Contrast alone doesn't cover color-blindness. A red/green pair can hit 4.5:1 and still be indistinguishable to someone with red-green color blindness if color is the only signal. The fix is redundant coding — an icon, a label, a shape — never contrast tuning alone.

Why this matters in interviews

"How would you verify this design is accessible?" is a very common frontend question, and it's a filter: candidates who answer "make sure the text is easy to read" are eyeballing. Candidates who answer "compute the contrast ratio between the rendered foreground and background, check it against 4.5:1 or 3:1 depending on text size, and don't trust opacity or gradients without re-measuring the actual painted color" are reasoning about a system with a testable, falsifiable rule — which is exactly the difference this platform is built to drill.