Color Accessibility Audit Checklist

Core Workflow

This checklist answers one practical question: can this palette be used in production screens without blocking reading, control detection, or user trust? You should run it before tokens are added to components, before CSS lands in a shared source file, and before the design language expands into variants.

Run it for one source palette and one destination surface at a time, for example mobile landing page, admin dashboard, or in-app campaign panel. If the target context is unclear, do not start. The strongest audits begin with a bounded scope statement and a concrete pass/fail target.

Scope and Intake Checks

Before any contrast math, capture what is being judged. Missing context causes most false passes.

• Record the source and destination path, for example brand header, form card, error banner.
• Record device constraints such as desktop dark mode, mobile bright mode, and any reduced-contrast accessibility profile in product requirements.
• Store exact hex or token values, not copied screenshots. The same color token can fail in one theme and pass in another.
• Mark every role before calculations: primary text, secondary text, title text, border, disabled, action, danger, success, link, graph fill, and decoration.
• Confirm export format constraints and token naming rules are known so the audit output can be used directly in the next handoff.

Decision-ready Role Mapping

Do not test all possible pairs first. Test role pairs that carry meaning. Roles are the practical unit of decision making.

Start with this mapping pattern:

• Role label: body text. Allowed pairing roles: body background, card background, panel background.
• Role label: headline. Allowed pairing roles: same as body text unless separate emphasis is required.
• Role label: link. Allowed pairing roles: links must remain distinguishable under hover and focus changes.
• Role label: control (button, chip, toggle). Requires text + surface + border/indicator coherence, not contrast alone.
• Role label: disabled state. Must read as disabled in context without being mistaken for active data text.
• Role label: decorative accents. Mark explicitly as non-text and non-action unless documented otherwise.

Practical Workflow

Run these steps in order. Each step must produce an output artifact you can pass to another person without interpretation.

1. Split the palette into semantic groups: background, border, text, state, and decorative. Rename each value with a role label.
2. Build a working contrast matrix for every text-on-surface and icon-on-surface pair in the target context.
3. Filter out failed pairs that are hard breaks, especially body text on primary cards, link text on gradient surfaces, and success/error text on busy backgrounds.
4. For each remaining candidate, test hierarchy by comparing intended emphasis levels. A pair can pass contrast and still collapse visual order.
5. Create a replacement plan that keeps maximum brand intent: tweak luminance first, then saturation, then hue drift only if needed to recover hierarchy.
6. Re-run checks immediately after each adjustment. Do not batch many updates before reassessment.
7. Collect findings into a compact handoff note with color names, source values, decision status, and exact reason for keep/reject.

Decision Rules

Use explicit rules so the checklist remains operational at handoff.

• Rule A: If any required text role cannot meet a safe pair with any real surface, reject that role assignment and choose a safer role mapping.
• Rule B: Decorative-only colors must not carry status, alert, or primary action meaning, even if they look brand aligned.
• Rule C: If two colors compete for the same purpose, keep only the stronger pair for that role. Remove or archive alternatives.
• Rule D: If more than 20 percent of tested pairs are uncertain, stop and reduce scope before continuing.
• Rule E: Every rejected pair must have one clear reason and one replacement path; otherwise the change is not complete.
• Rule F: If a color only passes in one context and fails in another, split tokens by theme and document both contexts explicitly.

Verification Limits and Stop Conditions

The checklist is not a full accessibility certification. It is a gating gate before implementation. If limits are hit, stop and escalate.

• Stop condition: roles are mapped, all required pairs are tested, risky pairs are either replaced or explicitly deferred, and export names are final for the target release.
• Stop if there is uncertainty about text state combinations such as focused, hover, disabled, selected, and error with unknown interaction patterns.
• Stop if brand or legal constraints force multiple near-identical tokens; escalate with a decision note rather than shipping ambiguous values.
• Stop if token count is low confidence. Too many tiny tweaks usually indicate the source palette needs a rewrite instead of patching every pair.

Common Rework Traps

These traps make teams fail at the implementation boundary even after a tidy audit spreadsheet.

• Using visual preference over role accuracy, then labeling failures as acceptable exceptions.
• Checking only the hero section and skipping forms, sidebars, modals, banners, and empty-state blocks.
• Assuming color contrast alone guarantees usability while ignoring icon cues, spacing, and typography scale.
• Keeping “brand gradients” as default for status messaging without a documented fallback color for small text.
• Exporting only final CSS values and dropping the decision log, making the next reviewer repeat work from scratch.

Handoff Checks

Before transfer, confirm the handoff is readable by someone new to the file and still unambiguous in six months.

• Each approved text role has one safe background and one approved variant for emphasis.
• All non-text roles are tagged as decorative or supportive in plain notes.
• Rejected combinations list the failing context and replacement color or pattern.
• Final export file names include scope tags, such as v1-dashboard-mobile-light, and are linked with the decision log.
• Related team members can validate by opening the same source and running one short checklist pass.

Related Tool Handoff

Open Color Accessibility Auditor after role mapping and decision rules are fixed. Use it for mechanical validation, then compare the generated results to this checklist before replacing source files.

Keep one package for handoff: source list, decision log, approved token list, and notes on blocked pairs. If the package is clear, implementation can continue without style debates.

Frequently Asked Operational Questions

Do I need exact contrast formulas to use this checklist?

Use whichever contrast method your team uses, but the checklist requires consistent interpretation across the same role set and context. Inconsistent methods create inconsistent handoffs.

Can decorative colors be kept even if they do not pass text contrast?

Yes, if they are locked to decoration-only roles with no behavior expectation. Document that lock clearly so future contributors do not reuse them as controls.

When should I escalate to a deeper review?

Escalate when roles change after implementation, when token count keeps growing, or when a new component family introduces new interaction states not covered in this audit.

Decision and Handoff Notes

A practical audit is useful when the next owner can see exactly what changed, why it changed, and what remains blocked.

• Confirm input before edits: target platform, page type, brand constraints, file format, and whether the audit is for a live release or internal experiment.
• Keep the smallest effective change. Remove uncertainty before adding extra alternatives.
• Record handoff-critical values such as token names, hex or color values, state mappings, and the final scope tag.
• Stop when roles, checks, and names are stable enough for implementation and the next team member can pick up from the checklist without additional interviews.
• Run one context test in destination rendering before public release so local screenshots do not become a substitute for actual layout behavior.