Audit Color Contrast Against WCAG with AI
Reads a list of foreground/background color pairs and returns contrast ratios, WCAG 1.4.3 (text) and 1.4.11 (non-text) pass/fail per pair, the contrast level achieved (AA / AAA), and closest WCAG-passing alternative per failing pair.
When to use it
- Reviewing a brand palette before product use.
- Auditing an existing UI for contrast violations.
- Designing a dark mode color set.
- Documenting contrast decisions in a design system.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a design systems engineer with deep accessibility background. You compute contrast ratios precisely (or describe the formula) and you don't conflate text contrast with non-text contrast.
</role>
<context>
WCAG contrast rules:
- **SC 1.4.3 (Contrast Minimum, AA)** — text vs background:
- Normal text: contrast ratio >= 4.5:1
- Large text (>= 18pt regular OR 14pt bold): >= 3:1
- **SC 1.4.6 (Contrast Enhanced, AAA)** — text:
- Normal: >= 7:1
- Large: >= 4.5:1
- **SC 1.4.11 (Non-Text Contrast, AA)** — UI components (form input borders, icon outlines, focus rings, custom check states): >= 3:1
Contrast formula: (L1 + 0.05) / (L2 + 0.05), where L1 is luminance of lighter color, L2 of darker. Luminance computed from sRGB → linearized RGB → weighted sum.
</context>
<task>
For the color pairs below:
1. Compute the contrast ratio per pair (or describe how — exact ratios optional).
2. Determine WCAG pass/fail per usage:
- Text usage: pass at 4.5:1 (normal) or 3:1 (large), AAA at 7:1 (normal) or 4.5:1 (large)
- Non-text (UI elements): pass at 3:1
3. For each failing pair, suggest a closest-WCAG-passing alternative (adjust foreground OR background, keep brand intent).
4. Note any pair that's borderline (within 0.1 of the threshold).
</task>
<input>
Color pairs (foreground / background, hex or CSS): {pairs}
Usage context per pair (text / large text / non-text UI): {usage}
Brand color constraints (which colors are locked): {constraints}
</input>
<constraints>
- Cite SC number per pass/fail decision.
- "Large text" definition explicit: >= 18pt regular OR >= 14pt bold.
- Non-text (UI) uses 3:1, not 4.5:1 — don't conflate.
- Alternatives respect brand-locked colors; only adjust the non-locked side.
- Borderline cases (within 0.1) flagged as risky.
</constraints>
<output_format>
Markdown table: Pair | FG | BG | Usage | Ratio | WCAG (SC + AA/AAA) | Status | Suggested alternative. Followed by a "Summary" paragraph (X of Y pairs pass) and a "Brand-color implications" paragraph if alternatives shift the palette.
</output_format>
Before writing, identify which pairs are TEXT vs UI element — the threshold differs.Example
Common pitfalls
- Model computes ratios incorrectly — high tolerance for hex codes that are visually similar. Use a tool to verify if precision matters.
- Non-text contrast (3:1) conflated with text (4.5:1) — they're different thresholds.
- Brand-locked colors ignored; alternatives suggest changing the brand color.
- Borderline cases (within 0.1 of threshold) marked PASS without note — they're at risk after any future palette shift.
Tips
- Use a contrast tool (axe, WebAIM Contrast Checker, Chrome DevTools) to verify computed ratios before publishing.
- Document accessible alternatives in the design system, not just per-component fixes.
- Pair with `wcag-2-2-aa-suite` for the rest of the visual accessibility surface.
- Re-audit when designers change neutrals or add new brand colors.
FAQ
AA is the legal baseline (4.5:1 for normal text). AAA is the enhanced standard (7:1). Most teams target AA; AAA is reserved for products serving users with low vision specifically. Don't pursue AAA at the expense of brand consistency unless your audience needs it.
Related prompts
Generate a WCAG 2.2 AA Test Suite
Returns a comprehensive WCAG 2.2 AA test suite organized by Success Criterion (perceivable / operable / understandable / robust) — each item with SC number, test method (manual / axe / Playwright @axe-core), pass criteria, and explicit coverage of WCAG 2.2's new criteria.
Open →Screen Reader Test Scenarios
Reads a component description and returns screen reader test scenarios with expected announcement text per reader (NVDA, JAWS, VoiceOver), recommended browser pairing per reader, navigation pattern, and clear pass/fail criteria.
Open →Keyboard Navigation Test Cases
Returns numbered keyboard navigation test cases covering Tab order, focus visibility, focus trap in modals/menus, Escape key behavior, skip links, focus return after modal close, and roving tabindex for composite widgets — with expected behavior per case.
Open →ARIA Patterns Validator
Reads a component's ARIA implementation (role + states + keyboard handling) and validates against the matching WAI-ARIA Authoring Practices Guide pattern — flagging missing required roles, missing required states/properties, incorrect keyboard interactions, and prohibited attribute use.
Open →