Accessible Color Pair Generator

Enter a background, choose a 3:1, 4.5:1, or 7:1 contrast target, and get copy-ready light and dark text candidates.

Background

Contrast target

Preview background

—These are sRGB contrast candidates. WCAG contrast is only one accessibility requirement; type size, state cues, focus, and non-color indicators still matter.

Pair audit, AA/AAA matrix & nearest passing fixes

The existing candidate generator remains first. This optional audit checks an exact foreground/background pair, shows the WCAG 2 contrast ratio against normal/large AA and AAA thresholds, previews the pair, and finds the nearest darker and lighter HSL-lightness adjustments that meet the selected target.

ForegroundBackgroundFix target

Readable sample Aa · link · button label

Contrast audit evidence

Suggestions preserve the foreground HSL hue/saturation while changing lightness; review the real component before adopting a token.

Color and accessibility boundaries

HEX/RGB/HSL/HSV/OKLCH conversions are numerical color-model operations. CMYK output is an RGB-derived approximation rather than ICC-profiled print proofing. WCAG contrast ratios measure luminance contrast only and do not certify a full interface. Color-blindness previews are design simulations, not medical tests.

How to use the Accessible Color Pair Generator

Enter a background and choose a contrast target. The browser searches lightness candidates and returns copy-ready text colors that meet the selected sRGB contrast ratio.

What the result means

4.5:1 is the WCAG AA threshold for typical normal text and 7:1 is the AAA normal-text threshold. Contrast alone does not guarantee an accessible interface.

Practical guide and verification

Use the tool first, then apply these checks to verify inputs, interpret the result, and hand it off without displacing the primary workflow.

Test the actual foreground and background pair

A generated candidate is only useful when it is tested against the background that will really appear in the interface. Gradients, images, opacity, blending, overlays, and state changes can alter the effective color seen by the user. Audit the literal foreground/background pair first, then repeat the check in hover, focus, disabled, selected, dark-mode, and error states. Keep the measured contrast ratio with the exact color tokens used in the shipped design.

Use the correct WCAG threshold for the content

Normal text, large text, and non-text graphical objects do not all share the same threshold. Choose the target that matches the role and size of the content rather than selecting a lower target just to make a preferred palette pass. A strong ratio also does not replace requirements for readable type, focus indication, labels, state communication, or non-color cues. Treat contrast as one measurable accessibility check within a broader interface review.

Prefer the smallest controlled color change that passes

When a brand or component color fails, changing only lightness while preserving hue and saturation can provide a predictable starting correction, but it is not a design rule. Compare both darker and lighter passing alternatives, inspect the visual result, and check surrounding components before adopting one. The numerically closest correction may still conflict with hierarchy, disabled-state conventions, or a design system token scale, so record the final approved token rather than only the automatically suggested value.

Recheck exported tokens in the production color space

WCAG 2 contrast calculations use sRGB relative luminance. If the design source uses wide-gamut colors, alpha compositing, CSS color functions, or a different color-management workflow, reduce the final rendered pair to the effective sRGB colors used for the WCAG check. Copying a passing hex pair into CSS is convenient, but the production page remains the final verification target because inherited opacity, overlays, browser rendering, and component state can change the effective contrast.