AI-Generated Color Palettes: Check Contrast Before Shipping

A generated palette is a set of suggestions, not an accessible interface. Five harmonious swatches can produce unreadable labels, invisible borders and ambiguous error states when assigned to real components. The important unit of review is the foreground and background combination in context, not the individual colour.

Use AI to explore directions and propose naming schemes, then verify the values with deterministic tools and browser testing. This keeps creative exploration quick without treating an assistant's description of a palette as evidence that it meets accessibility requirements.

Turn swatches into semantic roles

Start with semantic colour roles such as page surface, raised surface, primary text, secondary text, interactive accent and error indication. Explain where each role appears before asking for alternatives. A palette without roles leaves every designer and developer to invent their own combinations.

Separate primitive values from usage decisions. A blue scale might supply several possible values, but an action-background token should point to the specific shade approved for that use. This two-layer token model makes it easier to adjust contrast without renaming every component or scattering literal colours through the codebase.

Ask for a restrained initial proposal. Request light and dark surface roles, readable text roles and a small set of status colours. Avoid generating dozens of intermediate shades before establishing whether the core pairs work. Extra options increase the number of combinations that need review.

Use the AI UI design tools directory to compare palette and interface workflows, but evaluate exported values rather than promotional previews. A tool that labels a palette accessible may have checked only one text colour against one surface, not all the combinations your interface permits.

Normalise values before measuring

Generated output can mix hexadecimal, RGB, HSL and more recent colour formats. Use the colour converter to normalise supported values into the format your implementation and checking tools accept. Keep the original values alongside conversions so rounding or gamut changes can be investigated.

Treat colour conversion as a representation step, not an accessibility correction. Converting an unsuitable grey from HSL to hexadecimal does not improve its contrast. Likewise, a model's estimate of a ratio is not a measurement. Calculate from the actual rendered colours using a reliable checker.

For transparency, identify the background behind the translucent layer. A partially transparent label or overlay has no single effective appearance independent of what sits underneath it. Gradients and imagery need checks at the weakest relevant location, not just at a convenient midpoint.

The MDN CSS colour reference helps clarify supported syntax and behaviour. Pay particular attention when wide-gamut suggestions are converted for a workflow that assumes sRGB. Gamut handling and rounding can change the final result, so verify the values that the browser actually uses rather than a screenshot of an earlier design.

Check the pairs that users encounter

Build a list of approved foreground and background combinations. Include body text on page surfaces, muted text on cards, button labels, links in paragraphs and text inside status badges. Test dark mode separately; reversing light and dark values does not automatically produce a balanced or compliant theme.

The WCAG contrast minimum guidance explains the usual AA thresholds: at least 4.5:1 for normal text and 3:1 for qualifying large text. Large text has a specific definition, generally 18 point or 14 point bold, so do not treat every heading as automatically eligible.

Use a contrast margin rather than choosing values that barely pass after rounding. A displayed ratio rounded to 4.5 may conceal an underlying failure. Check the tool's precision and avoid relying on thin type or anti-aliasing to make borderline combinations feel readable.

A prompt can help prepare the audit, but should not replace it:

Assign these palette values to semantic interface roles.
List every foreground/background pair the roles permit.
Include normal, hover, selected, error and focus states.
Do not claim WCAG compliance or invent measured ratios.
Mark combinations that require calculation and browser review.

Keep the resulting pair inventory with your design tokens. It gives reviewers something concrete to validate and prevents accidental use of an accent shade as small body text simply because both belong to the same brand palette.

Review controls and state changes

Text is only part of the audit. Borders, icons and focus indicators may carry information needed to identify or operate a control. The WCAG non-text contrast guidance explains where 3:1 contrast requirements apply to relevant interface components and graphical objects, with important exceptions and context.

Inspect state transitions on real components. A selected tab needs a discernible selected state; an error field needs an explanation, not just a red outline. Pair status colours with text or an appropriate symbol so meaning does not depend on distinguishing red from green.

Test focus styling against every surface it can cross. A ring that works on a white page may disappear around a coloured button or inside a dark sidebar. If a component uses multiple layers, check the relevant adjacent colours rather than assuming one global focus token works everywhere.

Disabled controls have specific accessibility exceptions, but unreadable disabled labels can still confuse people. Explain unavailable actions where useful and avoid making essential instructions look disabled. Practical readability remains a design responsibility even when a particular contrast requirement does not apply.

Lock approved combinations into the workflow

Document which tokens may be paired and which uses are prohibited. A component library should make the approved combination easy and the unsafe combination difficult. Prefer semantic variants such as danger or secondary over arbitrary foreground and background overrides in every instance.

Add regression checks where your stack supports them, especially when themes or tokens change. Automated checks can catch many failures, but they may miss content over images, transient states and unusual compositing. Include manual browser review for those cases and test representative pages rather than isolated swatches alone.

Read the usable UI prompting guide when feeding tokens back into generation. Give the model approved roles and explicit restrictions instead of asking it to improvise a fresh palette on every screen. This reduces drift between concepts and production components.

Record the checked values, context and date with the palette decision. When branding changes, repeat the pair audit rather than assuming that a visually similar replacement inherits the earlier approval. The deliverable is a verified usage system, not a screenshot of attractive colours.

Key takeaways

• Assign semantic roles before judging an AI-generated palette.
• Normalise values, then calculate contrast from actual foreground and background pairs.
• Check text, controls, focus indicators and changing states separately.
• Preserve meaning with labels or symbols rather than colour alone.
• Document approved combinations and recheck them whenever tokens change.