You've designed what looks like a perfectly readable interface. The designer signed off, the PM signed off, and the first user who actually tries to read your light-gray-text-on-white-background calls it "improbable" in a bug report. Color contrast failures are the most common accessibility finding in web audits (roughly 80% of WCAG AA failures in real audits involve contrast) and the one that most consistently gets shrugged off as "aesthetic choice" until a legal letter or a screen-reader user makes it impossible to ignore.
The WCAG contrast ratio is a number from 1:1 (same color, invisible text) to 21:1 (pure black on pure white). The AA cutoff that matters for most commercial work is 4.5:1 for normal body text and 3:1 for large text (18.66px+ bold, or 24px+ regular) and UI component boundaries. The stricter AAA level is 7:1 for normal text and 4.5:1 for large. That 4.5:1 threshold is where most "clear-looking" UI shades suddenly fail โ a light gray like #999 on white is around 2.8:1 and fails all levels; a medium gray like #767676 on white is 4.54:1 and passes AA but not AAA, and is in fact the lightest gray that passes AA against white with any margin at all.
This tool takes two colors (foreground and background, each as hex / RGB / HSL), shows you the live WCAG 2.x contrast ratio to two decimals, and states explicitly which level it passes or fails: AA (normal text), AA (large text only), AAA (normal text), or "fails AA." It re-evaluates in both directions because contrast is symmetric and frequently a designer changes the background without re-checking โ you want to catch that instantly.
Beyond the ratio, it shows how the pair renders to simulated protanopia, deuteranopia, and trachromatic vision (color-blindness variants) and notes when two colors that look distinct to you are the same to a color-blind viewer and to a printer. That last failure mode โ two "different" chart series that are actually identical for a deuteranopic user โ is a separate WCAG requirement (1.4.1, "use of color") that the contrast number alone doesn't capture.
Simulations to watch for: your green/red pass-fail icon that reads identically to ~5% of male users, yellow/white text that's 1.1:1 even though it "looks bright," and light theme text that looks fine in isolation but fails against the tinted background a component gets in context.
The "swap" button lets you flip fg/bg with a click, and the "dark mode in context toggle" shows how your chosen pair performs against both a dark (#121212 or similar) and light (#FFFFFF) page background simultaneously โ because components don't live in isolation and a color that passes on white may fail on your sidebar's dark tint.
Where this tool actually helps in a workflow: a post-design QA pass where you feed in every text/background pair from your design tokens and flag anything below AA before it ships, verifying that your proposed gray scale (each step from #000 to #FFF) stays readable against the backgrounds it's placed on, selecting a link color that passes AA against the body background and also distinguishes itself from surrounding non-link text at 3:1 contrast (separate requirement from link-vs-non-link contrast), building a "verified accessible swatch library" your team can pull from instead of re-picking and re-testing, documenting your contrast reasoning for VPAT / accessibility-conformance reports (the tool exports a per-pair record), and answering the "can I use this exact hex?" question from a copywriter who wants to quote a light-themed pullquote over a dark section of an article.