Color contrast rules that also make your brand look better

WCAG contrast requirements (a minimum contrast ratio between text and background) get introduced to design teams as a constraint, something accessibility compliance forces onto an otherwise freer design process. In practice, working within those constraints tends to produce cleaner, more confident design, not a compromised version of what the brand wanted.

We've watched this reframe change how a design team talks about contrast internally, from a compliance box to check right before launch to a design principle worth applying deliberately from the first mockup. Teams that make that shift stop experiencing contrast fixes as late-stage rework and start experiencing them as a normal part of choosing colors in the first place.

Light gray text on a white background, a common contrast failure, usually happens by accident: a designer working on a large, color-accurate monitor in a dim room doesn't notice how illegible it becomes on an average phone screen in daylight. Fixing contrast issues often just corrects an unintentional legibility problem that was already hurting the design, accessibility requirement or not.

We show clients side-by-side screenshots of a low-contrast design viewed on a calibrated studio monitor versus the same design viewed on an average phone in bright sunlight, since the gap is dramatic and immediately obvious once you see it side by side. Most clients approve a contrast fix on the spot after that comparison, without needing to be convinced further on accessibility grounds alone.

When color alone can't carry a visual hierarchy (a light accent color that fails contrast for body text) designers lean more on type weight, size, and spacing to create emphasis, which tends to produce a more robust hierarchy that still reads clearly even for users with perfect vision, not just those the requirement was written for.

A hierarchy built primarily on subtle color variation is also more fragile across contexts than one built on weight and size: it can look fine on a bright, color-accurate screen and fall apart on a dim phone, a printed handout, or a screen with a warm color temperature setting. A hierarchy built on weight and spacing holds up consistently across all of those contexts, which is a real, practical benefit independent of any accessibility requirement.

Checking contrast ratios during the design phase, rather than as a compliance check right before launch, means fixes happen while the design is still flexible, as small adjustments rather than late reworks. A contrast issue caught in a Figma file costs minutes to fix. The same issue caught in a compliance audit after development costs considerably more.

We run an automated contrast check as part of the design review at each major milestone, flagging any color pairing that falls short before it ever reaches a developer's hands. That single automated step has caught the large majority of contrast issues we would otherwise have found much later, when fixing them meant touching shipped code instead of a still-editable design file.

Running a full contrast audit on an existing brand's color palette sometimes reveals that one or two accent colors, used in the original brand guidelines for years, simply never pass contrast requirements against white or the brand's own background colors in any practical text application. That's worth surfacing to the client directly rather than quietly working around it forever.

We usually recommend keeping the accent color for large graphic elements and swapping it out specifically for small text applications, which preserves the brand's visual identity everywhere it's genuinely recognizable while fixing the one context where the color was actually causing a real, measurable legibility problem for real users.

A color pairing that comfortably passes contrast in light mode doesn't automatically pass in a dark mode variant, since the relationship between text and background inverts and the same accent color can read very differently against a dark surface than it does against white. We treat dark mode as its own full contrast audit, not a simple inversion of the light mode palette, since assuming otherwise is a common source of accessibility regressions that only show up for users who've actually switched their device to dark mode.

This extra audit pass is genuinely worth the additional time it takes, since dark mode adoption among users has grown enough on most platforms that a broken dark mode palette isn't an edge case anymore, it's a real experience for a meaningful share of any product's actual audience.

A browser extension that overlays contrast ratios directly on a live page, combined with a Figma plugin that flags failing pairings before a design is even handed off, covers the large majority of contrast checking we do without requiring a dedicated accessibility audit tool for routine work. We save the more comprehensive audit tools for periodic full-site reviews rather than everyday design checks, since the lightweight tools are fast enough to use constantly without slowing down the actual design process.

We bring up contrast requirements early in a design engagement, before a client asks about accessibility specifically, framing it plainly as a legibility improvement that happens to also satisfy a compliance standard, rather than leading with the compliance angle alone. Clients respond to that framing more readily than to a purely compliance-driven pitch, since it connects the requirement to something they already care about, a design that reads clearly for actual customers, rather than to a legal risk they may not feel is urgent yet.

We keep this argument in reserve for the rare client pushback we do get, usually a request to use a specific low-contrast color regardless of the ratio, because it's part of a brand they're emotionally attached to. Reframing that specific conversation around real customers straining to read real text, rather than an abstract rule, tends to resolve it faster than citing the WCAG guideline number ever does on its own.