Right before a design or website goes live is a natural, valuable checkpoint for a final, focused accessibility color review — not to catch every conceivable edge case, but to confirm the highest-impact, most common issues have genuinely been addressed before real users encounter them. None of these checks require specialized expertise to run, just a bit of deliberate, structured time set aside specifically for this purpose before a project goes live, rather than assuming everything was already handled adequately along the way. Building this specific habit genuinely pays for itself many times over across the entire life of a project, not just at the moment of launch.

Checking all primary text-and-background combinations

Every meaningfully distinct text-and-background pairing used throughout the actual design — not just the most obvious body text, but headings, captions, labels, and any other genuinely distinct combination — checked against at least the WCAG AA thresholds (4.5:1 normal text, 3:1 large text), covers the most fundamental and highest-impact check on this list.

Checking non-text interface elements

Meaningful icons, form field borders, button outlines, and other functional interface components checked against the 3:1 non-text contrast threshold, covered in more detail in this site's non-text contrast guide, catches an entire category of accessibility issues that a text-only review would miss completely.

Confirming color isn't the only way important information is conveyed

Reviewing every place color is used to communicate meaning — error states, success states, required fields, status indicators — and confirming each one also has a non-color signal (an icon, a text label, a pattern) ensures the same information reaches colorblind users, not just those with typical color vision.

Testing in realistic, imperfect viewing conditions, not just ideal ones

Viewing the actual finished design on a phone outdoors, on an older or lower-quality monitor, or with screen brightness deliberately turned down, rather than only reviewing on a single well-calibrated primary work display in ideal lighting, surfaces real-world contrast problems that a review under ideal conditions alone can miss.

Running a color-blindness simulation pass

Checking the finished design, or at least its most critical pages and interactions, through a color-blindness simulation tool specifically to confirm important distinctions remain genuinely perceivable under different types of color vision deficiency, not just under typical color vision.

A condensed final checklist

  • Every text-and-background pairing meets at least WCAG AA contrast.
  • Meaningful icons and interface components meet the 3:1 non-text contrast threshold.
  • No essential information relies on color alone, without a non-color signal alongside it.
  • The design has been checked under realistic, imperfect viewing conditions, not just ideal ones.
  • A color-blindness simulation pass has been run on key pages or interactions.

Treating this list as a living document, not a one-time script

Revisiting and updating this checklist as a project's design system evolves, rather than treating it as a fixed, one-time script written once and never revisited, keeps it genuinely useful rather than gradually becoming outdated as new components and patterns get added to the project over time.

Try the Contrast & A11Y tool yourself — free, instant, nothing sent anywhere.

Open the tool

Frequently asked questions

Is this checklist meant to catch every possible accessibility issue?

No, it's specifically focused on the highest-impact, most common color-related accessibility issues; a comprehensive accessibility audit covers considerably more than color alone, including things like keyboard navigation and screen reader compatibility.

How long does a check like this typically take before launch?

For a project that's already built contrast checking into its regular workflow along the way, a final pre-launch pass is usually quick, often well under an hour; it takes considerably longer if it's the first time contrast has been checked at all, late in the process.

Should this checklist be run once at the very end, or throughout a project?

Both are genuinely valuable — checking throughout catches issues early when they're cheap to fix, while a final dedicated pass right before launch serves as a last, focused safety net for anything that may have been missed along the way.

Is a color-blindness simulation check really necessary if contrast ratios already pass?

Yes, it's still worth doing separately, since contrast ratio alone doesn't fully account for hue-based distinctions that specifically affect colorblind users, which a simulation tool can reveal in a way a standard contrast check alone won't catch.