How to check color contrast

A contrast checker compares the relative luminance of foreground and background colors and reports a ratio. WCAG uses that ratio to set minimum thresholds for text and certain visual interface elements. The number is useful for checking a specific color pair, but it cannot judge every part of readability, accessibility, or interaction. Evaluate the colors people actually see in context, then review the rest of the experience as well.

Apply the right threshold to text

Under WCAG 2.2 Success Criterion 1.4.3 at Level AA, ordinary text and images of text need a contrast ratio of at least 4.5 to 1 against their background. Large-scale text has a lower threshold of 3 to 1. WCAG defines large text using at least 18 point regular or 14 point bold text, with equivalent sizes for other writing systems. This is a defined exception, not a general license to make every heading faint.

Do not round a near miss upward: a result below the threshold does not meet it. Placeholder text and text that appears on hover or keyboard focus still need sufficient contrast when the criterion applies. A checker can evaluate a selected pair, but it may not know whether the text is large, bold, part of a logo, inactive, decorative, or over a changing background. Make the context explicit when interpreting the result.

Check meaningful controls and graphics separately

Text contrast and non-text contrast are separate WCAG criteria. Success Criterion 1.4.11 addresses the visual information needed to identify user-interface components and meaningful parts of graphics. For applicable components and graphical objects, the required visual information generally needs at least 3 to 1 contrast against adjacent colors. This can include the outline of a text field, an icon that communicates an action, or a chart element needed to understand the data.

A decorative shape does not need the same treatment as a control that users must find or operate. Inactive interface components and certain incidental or logo cases have exceptions in the criteria. Do not use those exceptions to excuse a whole design without checking the actual purpose of each element. For an input, examine the boundary, label, entered value, error state, and focus indicator rather than testing only the page's main text color.

Calculate the colors that will be rendered

The contrast ratio is based on relative luminance, a measure of how light or dark a color appears to the human visual system. A color contrast tool converts the foreground and background colors into linearized RGB values, calculates luminance, and compares the lighter and darker values. Hue alone is not enough: two colors can look different in hue and still have too little light-dark contrast for readable text.

Use the colors that actually appear after opacity, overlays, gradients, images, and theme rules have been applied. A translucent text color over a patterned image does not have one fixed background value. A design token might pass against the main surface but fail over a card, error banner, or highlighted selection. Check the final rendered combinations at normal zoom and with the themes or states users can choose.

Test every state and destination

A page contains more color pairs than its default view suggests. Check links in their normal and visited states, buttons on hover and focus, disabled controls, selected tabs, form errors, success notices, tooltips, and text placed over images. Focus outlines and meaningful icons may fall under non-text criteria even when their nearby text passes. If a component changes color after an action, verify both the initial and resulting states.

Reusable design tokens help teams keep combinations consistent, but one token can be used over surfaces with different luminance. Build a short matrix of foreground, background, and state combinations for the parts people must read or operate. Recheck the matrix after changing a brand palette, adding a theme, swapping a font weight, or placing a component on a new surface. Small changes in color can move a borderline pair below a threshold.

Use a checker as one part of an accessibility review

Passing a contrast ratio does not guarantee that text is comfortable to read. Very small type, thin strokes, long lines, tight spacing, motion, glare, and unfamiliar wording can still make a page difficult. Some people need stronger contrast than the minimum, so generous contrast can be a good design choice even where a lower ratio is permitted. Avoid using color as the only way to distinguish meaning; add text, shape, pattern, or another clear cue.

A contrast checker does not inspect screen-reader names, keyboard order, focus visibility as a whole, zoom reflow, or whether the content is understandable. Use keyboard testing and assistive technology checks alongside visual inspection. Ask people with different access needs to review important workflows when possible. WCAG is a useful conformance framework, but a single number cannot tell you whether a control is easy to discover, operate, and understand in a real interface.

Improve a failing pair without losing its purpose

If a text pair fails, darken the foreground or lighten the background until it clears the relevant threshold with room to spare. If the background must remain, consider a stronger font color or a solid surface behind the text. For controls and icons, strengthen the boundary or fill that communicates the component. Retest after applying opacity or overlay effects because the final color may differ from the design value you started with.

Make sure the adjustment still fits the product's hierarchy and does not make another state fail. A bright accent can work for large headings but fail for small labels; a color chosen for text may be too subtle for an input border. Keep the relationship between foreground and surface in a documented palette, then test the rendered page rather than relying only on a design swatch. Preserve visible focus and other non-color cues while refining the palette.

Use SafeStack's checker with a deliberate sample

SafeStack's Color Contrast Checker accepts foreground and background hex colors and reports the calculated ratio along with common AA and AAA text thresholds. It is a focused calculator, not a full WCAG audit. Enter the colors from the actual interface, compare the result with the applicable text size or non-text requirement, and preview the pair in context. If the page uses transparency, a photograph, a gradient, or multiple overlapping layers, inspect the rendered result separately.

Keep a record of the color pair and the element it represents when reviewing a design system. For example, note whether a token is intended for body copy, large display text, a control boundary, or a decorative accent. That context prevents someone from reusing a passing pair for a different purpose without testing it. Recheck the final page after implementation, since browser rendering and opacity can alter the values that users actually see.

Quick checklist

• Use at least 4.5:1 for ordinary text and 3:1 for qualifying large text at WCAG AA.
• Check meaningful controls and graphics against the applicable non-text criterion.
• Test every interactive state and the rendered background.
• Review keyboard focus, zoom, and non-color cues along with contrast.

Try it locally

Use these related utilities to turn the note into a practical workflow.

• Color Contrast Checker
• Color Palette Generator

Learn how this material is prepared in the SafeStack Editorial Policy.