Accessible Brand Color System Audit

Use this prompt to audit a brand palette as a working color system. It converts raw hex values and interface roles into a contrast matrix, token recommendations, exceptions, and a remediation order that a designer and developer can verify.

Act as an accessibility-focused design-systems reviewer.

INPUTS
- Brand colors with hex, RGB, HSL, or design-token values
- Intended roles: text, background, border, icon, focus, status, chart
- Text sizes and weights used in the product
- Required standard and level, such as WCAG 2.2 AA
- Screenshots or component inventory when available

TASK
1. Normalize every color into a named token and record its current role.
2. Test each foreground/background pair required by the component inventory.
3. Report the contrast ratio, applicable threshold, pass/fail result, and the exact UI role.
4. Separate confirmed measurements from missing inputs. Never estimate a ratio from a screenshot.
5. For failures, propose the smallest token change that preserves the brand hierarchy. Show the replacement value and re-tested ratio.
6. Check non-text controls, focus indicators, links, disabled states, error/success states, and charts that rely on color alone.
7. Return: executive summary, contrast matrix, token changes, component risks, exceptions, and a prioritized remediation plan.

QUALITY RULES
- Do not claim compliance from palette values alone; coverage depends on actual component pairings.
- Do not use color as the only signal for state.
- Mark unavailable font size, weight, opacity, blend mode, or background as NEEDS INPUT.
- Include a short manual verification checklist for the implemented interface.

How to Supply the Palette

Give the model token names and roles, not just a list of colors. For example, provide text-primary #172033 on surface-default #FFFFFF at 16px/400. That makes the result testable and prevents the same color from being evaluated against an irrelevant background.

Worked Example

Suppose a cyan link token is used on both white and dark navy. The audit must create two rows because contrast depends on the pair. If cyan fails on white, the fix may be a darker link token for light surfaces while retaining the original cyan on dark surfaces. The report should re-test both pairs and flag hover, visited, and focus states for manual review.

Failure Checks Before Approval

• Every measured pair maps to a real component or documented future use.
• Large-text thresholds are used only when size and weight are known.
• Opacity, gradients, images, and overlays are not treated as flat colors.
• Status and charts have a second cue such as text, shape, pattern, or icon.
• Suggested replacements are re-measured, not described as “more accessible” without a ratio.

Related Practical Resources

Use the AI website design prompts to apply the token decisions to interface concepts and the accessible urban library concept prompt as a second example of translating accessibility goals into concrete design constraints.

Frequently Asked Questions

Can a palette itself be WCAG compliant?

No. Accessibility depends on how foreground and background colors are paired, along with text size, weight, component state, and non-color cues.

Should the model calculate contrast from a screenshot?

No. Supply exact color values or verify sampled values with an accessibility tool before accepting a measurement.