Open the tool, drop in a brand colour like #2A5CAA, and set it against white. The True-Contrast Smart Palette tells you the pairing sits at roughly 5.1:1, which clears the threshold most teams design against for body text. Nudge that blue two shades darker and the ratio climbs; nudge it toward a lighter, brighter tone and it can drop below the line without the colour looking obviously weaker to the eye. That gap between what a colour looks like and what it measures is the whole reason a tool like this exists.
What the tool is actually checking
The Smart Palette takes two colours, a foreground and a background, and calculates how easily text set in one will read against the other. It is built around the Web Content Accessibility Guidelines (WCAG), the standard most UK and EU accessibility law and procurement rules point back to. WCAG's contrast ratio compares the relative luminance of two colours and expresses the result as a ratio, from 1:1 (no difference at all) up to 21:1 (pure black on pure white). The commonly cited targets are 4.5:1 for normal text and 3:1 for large text at the AA level, with AAA asking for more.
What the tool adds is the "smart" part: it suggests adjustments, nudging lightness or hue until a failing pair clears the threshold while staying visibly close to the colour you started with. That's the practical use case. A designer rarely wants a completely different colour; they want the one they picked to survive contact with an accessibility checklist.
Why the ratio can surprise you
Relative luminance weights the red, green and blue channels differently, because the eye is more sensitive to green than to blue or red. That's why a saturated blue and a saturated orange of similar apparent brightness can produce quite different ratios against the same white background. It also means two colours that look like they should contrast well, a mid-grey on a slightly darker grey, can fail badly, while a combination that looks visually flatter can pass. The maths doesn't track intuition, which is precisely why checking it earns its place in a workflow.
WCAG's ratio versus the newer perceptual model
WCAG 2.x's contrast ratio has one well-known weakness: it treats a 12px label and a 96px headline the same way, even though large, bold type is legible at lower contrast than small, thin type. The Accessible Perceptual Contrast Algorithm (APCA), developed for the draft WCAG 3 standard, tries to fix this by factoring in font size and weight, and by measuring contrast in a way that better matches how the human eye actually perceives light and dark text against a background. Its output isn't a ratio but an Lc value, roughly from 0 to 106 (or negative, for light text on dark backgrounds), and the size-aware thresholds mean a small grey caption might need an Lc of 60 or more while a large heading can get away with 45.
If the Smart Palette reports figures using both models, or lets you switch between them, that's worth understanding rather than skipping past. A pairing can sit comfortably above the old WCAG 2.x threshold and still read as thin under APCA's size-aware scoring, particularly at the small text sizes common in interface labels, form hints and legal copy. Neither model is simply "more correct": WCAG 2.x is what current law and most audit tooling still cite, while APCA is closer to how contrast actually behaves on screen. Design for the standard your project is actually held to, and treat the other as a second opinion.
Where a tool like this earns its keep
The obvious use is checking body text against a background before it ships, but the more useful applications sit slightly further out from that.
- Building an accessible palette from a brand colour. Most brand guidelines specify one or two hero colours without saying what they should sit against. Running that colour through a contrast tool against both white and near-black, then generating tints and shades that hold up at different text sizes, turns a single swatch into a usable range.
- Dark mode. A palette tuned for a light background rarely survives inversion unchanged. Text and UI colours that pass comfortably on white can fail against a dark grey background, because the luminance relationship has flipped.
- Data visualisation. Charts that rely on colour alone to separate categories need every colour pair to be distinguishable, including for the roughly 1 in 12 men with some form of colour vision deficiency. A contrast check between adjacent chart colours catches problems that a check against the page background never would.
- Design tokens. Once a palette is confirmed, it's worth encoding as variables. The CSS Variable Architect is the natural next step for turning a validated palette into reusable tokens.
A limitation worth knowing before you rely on it
Contrast checkers, this one included, only ever compare two flat colours. Real interfaces rarely offer that clean a pairing: text sits over photographic imagery, gradients, semi-transparent overlays and blurred backgrounds, none of which the tool can evaluate directly. A ratio calculated against a single background swatch tells you nothing about how that same text reads over the busiest part of a hero image behind it. Treat a pass here as a starting point for that scenario, not a guarantee, and check the actual rendered composition separately, particularly for anything layered over photography or video.
It's also worth remembering that contrast is one part of accessibility (a11y). A palette can pass every contrast check going and still fail a colour-blind user if colour is the only signal carrying meaning, or fail a screen reader user entirely if the underlying markup is wrong. The Design Glossary is a reasonable place to look up related terms like visual hierarchy or grid system if a project brief assumes familiarity you don't yet have.
Reading the output without over-trusting it
Use the numbers to catch pairings that look fine but measure poorly, and to defend a colour choice to a client or a compliance reviewer with something more concrete than taste. Don't treat a passing score as proof that the finished screen will be comfortable to read; screen calibration, ambient light, sub-pixel rendering and the viewer's own eyesight all sit outside what any calculator can account for. A tool that flags a likely problem is doing its job. Final judgement on whether real people can read real text on a real screen still belongs to a person looking at it.