ClaudeHowSupport Us

Using Claude to audit a design for contrast

Contrast is a checkable fact, not a matter of taste

Unlike a lot of design feedback, which is genuinely subjective, contrast between text and its background is measurable — there's an objective ratio, and a design either clears the bar for legible text at a given size or it doesn't. That makes it one of the more valuable things to actually audit rather than eyeball, because "does this look readable to me, right now, on my screen, in good lighting" is a poor substitute for a real check, and it's a check that's cheap to run properly once you know to run it at all.

Where contrast problems hide even in professionally-designed systems

Contrast failures aren't limited to obviously bad colour choices — they show up in places that look fine at a glance: light grey text used for de-emphasised secondary content, placeholder text inside a form field, text overlaid on an image or gradient background where the underlying colour varies across the text itself. These are exactly the cases most likely to fail a real contrast check while still looking acceptable in a quick visual pass, because the eye adapts and a design reviewer isn't consciously measuring anything.

Auditing systematically rather than spot-checking

A spot-check catches whatever combination happens to catch the reviewer's attention, which tends to be the more visually prominent text — headings, primary buttons — while missing the quieter, lower-contrast secondary and tertiary text that's just as much a real accessibility requirement. Auditing every distinct text-and-background combination in a design systematically, rather than sampling the ones that stand out, is the only way to actually confirm nothing was missed, since a low-contrast combination that doesn't stand out visually is exactly the one a spot-check is least likely to catch.

State-dependent contrast is its own separate check

A colour combination that passes at rest doesn't necessarily still pass in every interactive state — a hover or focus state that shifts a background colour can inadvertently move a previously-passing combination below the threshold, and this is easy to miss because the resting state is what usually gets audited, while interactive states are checked for behaviour but not re-checked for contrast. Treat each meaningfully different visual state as its own check, not an assumed pass carried over from the resting state.

Fixing a failure without breaking the design's intent

Where an audit finds a failure, the fix isn't always "make the text black" — that solves the technical problem while potentially discarding a deliberate design choice about visual hierarchy or emphasis. A better fix usually preserves the original intent while adjusting the specific value that's failing — darkening a colour slightly rather than replacing it outright, or increasing text weight or size where that's a valid alternative path to legibility. Ask for a fix that satisfies the contrast requirement while staying as close as possible to the original design's visual language, rather than accepting the first technically-passing value offered.

Large text and body text are judged by different standards

Contrast requirements aren't uniform across all text — larger, bolder text is generally held to a more lenient standard than small body text, since larger text is inherently easier to read at lower contrast. An audit that applies one blanket threshold to every piece of text on a page, without distinguishing text size and weight, will either flag passing large text as a false failure or, more dangerously, pass small text that should have been held to the stricter standard. Apply the threshold appropriate to each specific text's actual size and weight, not one uniform number across the whole page.

Building this into a repeatable process

A one-time contrast audit only covers what existed at the time it was run — anything added afterward needs the same check applied again. Building contrast verification into how new components or design changes get reviewed, rather than treating it as an occasional standalone exercise, is what actually keeps a design accessible over time rather than momentarily compliant right after a single audit.

Verified 2026-08-08 against ClaudeHow facts module (src/data/facts/) — see /about/#accuracy.