How to Test an Accessible Color Palette for Websites and Apps

An accessible palette is a set of approved relationships

A hexadecimal value has no contrast ratio by itself. Contrast exists only between a foreground and an adjacent background. The same green can be excellent for white button text, too faint as small green text on a pale surface, and completely unsuitable as a subtle border on white.

This changes the testing question. Instead of asking “Is our blue accessible?”, ask “May our primary blue be used for normal text on the default surface?” or “Does the input border remain identifiable against the page background?” Specific questions produce reusable design rules.

Step 1: inventory the colors that are actually rendered

Begin with the delivered interface, not only the brand PDF or design-file swatches. Record solid colors, opacity, overlays, gradients, borders, shadows used as meaningful boundaries, visited links, status colors, chart series, and theme variants.

If a color uses alpha transparency, calculate or inspect the composited color over every expected background. A token such as “black at 45%” produces different final colors on white, gray, photography, and a dark theme.

Step 2: assign semantic roles before testing pairs

Role names explain where a color is allowed to appear. They also prevent a passing decorative shade from being reused as small text simply because it belongs to the same palette.

Prefer names such as text-primary and surface-error over names such as gray-700 and red-100 in component APIs. A scale name describes appearance; a semantic token describes intended use.

Step 3: build a useful contrast matrix

A full seven-color palette produces 21 unique pairs. A 20-color system produces 190. Most of those pairs will never appear together. Start with role combinations used by real components, then use a full matrix to discover safe alternatives and accidental combinations.

Use the DOFIW Color Palette Accessibility Checker to generate pairwise results, then annotate the combinations your components actually need. Verify critical individual pairs with the Color Contrast Checker.

Step 4: apply the threshold for the role

For WCAG Level AA, normal text needs 4.5:1 and qualifying large text needs 3:1. Meaningful visual information required to identify many interface components, states, and graphical objects generally needs 3:1 against adjacent colors under Non-text Contrast.

For a full explanation of the text thresholds, large-scale definition, and exceptions, read WCAG Color Contrast Explained.

Step 5: test component states, not just static tokens

A button can pass in its default state and fail after hover, selection, validation, or focus. Create a state inventory for every interactive component and check both its text and the visual information needed to identify the component or state.

• Confirm that hover styling does not make text or the component disappear against adjacent colors.
• Check focus indicators against the colors they touch. An outside outline is normally compared with the outside background.
• Check the selected mark inside checkboxes, radios, toggles, and menu items against its adjacent fill.
• Review error text, field borders, icons, and inline help as separate visual relationships.
• Treat inactive components according to the relevant exception, while still designing a state users can understand.

Step 6: remove color-only meaning

A palette can pass every luminance test and still fail users if color is the only way to identify information, an action, or a state. WCAG 1.4.1 requires another visual means when color carries meaning.

Add text, icons, patterns, shapes, underlines, or other visible distinctions. For data visualizations, label series directly when practical and combine hue with patterns or marker shapes. Do not assume a color-vision simulation proves that all meaning remains available.

Step 7: repeat the test in every visual context

Approved pairs are context-specific. A light-theme text token cannot automatically be used on a dark surface, and an overlay that works on one photograph may fail on another.

A repeatable palette-testing workflow

1. Collect rendered colors.Include opacity, surfaces, states, themes, and graphics—not only brand swatches.
2. Assign semantic roles.Describe what each token may do: text, surface, boundary, state, focus, or data.
3. List real adjacency pairs.Map components before generating every mathematical combination.
4. Calculate the full matrix.Use it to find approved alternatives and combinations that should be prohibited.
5. Apply role-specific thresholds.Separate normal text, large text, component cues, and meaningful graphics.
6. Review color-only meaning.Add visible labels, shapes, icons, patterns, or underlines where meaning depends on hue.
7. Test states and contexts.Cover focus, hover, error, selection, disabled, dark mode, images, and responsive layouts.
8. Document and enforce.Publish approved token pairs with examples and component rules for designers and developers.

Document combinations as contracts

A contrast spreadsheet is useful during an audit, but a design system needs rules that prevent regressions. For each semantic token, document allowed backgrounds, approved content sizes, component states, and prohibited combinations.

Add automated tests for token pairs where your codebase permits it, but keep visual and human review in the release process. Automation cannot decide whether information relies on color alone or whether a graphic part is required for understanding.

Common palette-testing mistakes

• Calling an individual color accessible without naming its adjacent color and role.
• Testing every mathematical pair but failing to document which combinations are permitted.
• Checking text contrast while ignoring boundaries, icons, charts, and state indicators.
• Using the large-text threshold for headings that do not meet the size and weight definition.
• Testing opaque hexadecimal values when the interface uses opacity or blending.
• Checking the default state only and missing hover, focus, selected, error, and disabled styles.
• Assuming red and green are distinguishable because both contrast with white.
• Reusing a light-theme palette in dark mode without rebuilding adjacency rules.
• Rounding a value below 3:1 or 4.5:1 up to the threshold.
• Treating a successful automated matrix as proof of complete accessibility.

Accessible palette checklist

Use the DOFIW color workflow

Frequently asked questions