Paste up to a practical palette of colors and identify which foreground/background pairs meet common text contrast thresholds.
Check every unique pair in one palette. Ratios follow the WCAG relative-luminance contrast formula for sRGB colors.
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.
The contrast ratio between two colors is useful evidence, but a real component also depends on text size, font weight, borders, states, icons, focus indicators, and surrounding colors. Use the matrix to identify weak pairs quickly, then test the actual foreground/background role each pair will have. A passing number does not automatically certify the full interface.
Different WCAG thresholds apply to ordinary text, sufficiently large or bold text, and meaningful non-text UI components. A palette may contain pairs that work for a large heading but fail for body text. Record the intended role instead of treating every pair above one threshold as universally interchangeable throughout a design system.
Hover, active, disabled, selected, error, and dark-mode states can combine colors that are not obvious in a single palette list. After reviewing the matrix, build a short inventory of actual component states and test those pairs directly. This prevents a palette from looking compliant in isolation while an interactive state introduces a low-contrast text or border combination.
Contrast helps with luminance separation, but users can also have difficulty when information is communicated by hue alone. Do not rely on green versus red, for example, without labels, icons, patterns, or other redundant cues. A contrast matrix is one accessibility check among several, and it should be combined with semantic labeling and keyboard/focus review.
WebToolArc