10 Common Color Accessibility Mistakes and How to Fix Them

1–2: Faint text and placeholder dependence

Mistake 1 is using low-contrast gray for essential instructions, metadata, or legal text. Fix it by defining approved text tokens and reserving very faint colors for genuinely nonessential decoration.

Mistake 2 is using placeholder text as the only form label. Placeholders disappear after typing and are often styled too lightly. Use persistent labels and treat placeholder copy as optional guidance.

3–4: Color-only errors and invisible focus

Mistake 3 is marking errors only with a red border. Add an error message, icon, summary, or other visible cue and connect it programmatically to the field.

Mistake 4 is removing the browser focus outline without a strong replacement. Create a focus ring that remains visible against the component and the surrounding background, including in dark mode.

5–6: Untested states and disabled controls

Mistake 5 is testing only the default component state. Hover, active, selected, visited, pressed, and autofill states can introduce new foreground/background pairs.

Mistake 6 is making disabled controls so faint that users cannot identify them. Disabled elements do not need to invite interaction, but their label and purpose should usually remain perceivable.

7–8: Ambiguous charts and text over images

Mistake 7 is distinguishing chart series only by hue. Add direct labels, markers, patterns, or line styles and check adjacent colors for sufficient separation.

Mistake 8 is placing text directly over variable photographs. Use a solid text panel, controlled overlay, or art-directed image area so the contrast does not depend on the underlying pixels.

9–10: Theme drift and content exceptions

Mistake 9 is assuming a palette remains accessible after dark mode, rebranding, or user theming. Retest token pairings in every supported theme.

Mistake 10 is allowing marketing pages, embedded widgets, and rich-text content to bypass the system. Provide accessible templates and run page-level checks so local exceptions do not undo the core design work.

A faster way to find color risk

Instead of checking isolated screens at the end of a project, audit the semantic color system first. List the combinations the product is allowed to use—such as text on surface, text on primary, border on surface, focus ring on background, and status icon on status surface. A matrix can expose impossible combinations before they spread across components.

Fix the system before fixing screens

If the same low-contrast border or color-only error state appears in dozens of places, changing each component independently creates drift. Update the token or component rule, document the permitted states, and then verify representative screens. Use the Palette Accessibility Matrix for broad pair screening and the Color Blindness Simulator to reveal places where hue differences carry too much meaning.