Color in UI: Meaning, Contrast, and System

Why can color never go alone?

Because not everyone sees colors the same way. According to the US National Eye Institute, about 1 in 12 men has color vision deficiency, with a much lower risk in women (NEI: Color blindness). Screens can also look poor in bright sunlight, at low brightness, or on weak hardware. If an error appears only in red, those people do not see it.

WCAG criterion 1.4.1 puts it this way: color cannot be used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing an element. Its examples are direct: required fields marked only in red, or one person’s sales in red and another’s in blue. A passing case is a required field with red text and an icon (W3C: Understanding SC 1.4.1).

The fix is almost always redundancy: text, an icon, a shape, or a pattern next to the color. Color stays useful, but it no longer carries the message on its own.

How much contrast is enough?

WCAG has two main criteria:

Two details matter. First, the 1.4.11 threshold applies to borders, icons, and the states of a control, not to inactive components such as a disabled button. Second, focus indicators must also reach 3:1 against adjacent colors (W3C: Understanding SC 1.4.11; W3C: Understanding SC 1.4.3).

To measure, the W3C formula is (L1 + 0.05) / (L2 + 0.05), where L1 and L2 are the relative luminances of the lighter and darker colors. Contrast tools do the math, but understanding the logic prevents choosing colors that look fine and actually fail.

Why are red and green a risk?

Because the most common type of color vision deficiency makes red and green hard to tell apart (NEI). A typical pattern uses green for “valid” and red for “invalid” with no other signal. For some users, those two states look nearly identical. If red and green indicate opposite actions, always add an icon (a check mark or an X) and text.

A quick test: convert your design to grayscale. If the meaning still comes across, the structure is sound; if not, a redundant signal is missing.

How do you organize a palette?

A functional palette separates colors by their role, not by their hue:

• Neutrals for backgrounds, text, and borders, with enough contrast to read.
• Brand color for the primary action and identity.
• Semantic colors for success, warning, error, and information, each paired with an icon and text.
• Surface colors for cards, panels, and selected states.

That separation connects to tokens: instead of using #D92D20 everywhere, you define color.error and apply it from the system. Changing the error hue then does not mean revising every screen. For the architecture of those names, see token architecture and the design system article.

When should you NOT use a broad palette?

• If the product has five brand colors and none has a clear role, the interface fills with hues that compete with each other.
• If every team adds its own error red, meaning becomes inconsistent and the palette loses value.
• If color is used only for decoration and not to communicate, the screen gains appeal but loses clarity. Reduce it.

Illustrative example

Illustrative example: a payment form marks fields with errors in red and correct ones in green. A person with red-green color blindness cannot tell which is which, and the form looks equally correct in every field. The team adds a warning icon and a line of text under each field with an error, and changes the success green to a blue. It also checks that the error text reaches 4.5:1 against the background and that the field border reaches 3:1. The form still uses color, but it no longer depends on it.

For the math behind contrast, see the color contrast math, or the accessibility UX article. And for how text and color work together in hierarchy, read typography for UI and visual hierarchy.

Common mistakes

• Marking errors, successes, or states with color alone.
• Using red and green for opposite actions with no other signal.
• Choosing very light colors on white backgrounds because they “look clean.”
• Checking contrast only for text and forgetting borders, icons, and focus states.
• Creating a new red in each component instead of using a shared token.
• Reviewing the palette on one screen only, not in dark mode.

What you can do tomorrow

1. Convert your most-used screen to grayscale and note which meaning gets lost.
2. Check the contrast of your error and success states, including borders and focus.
3. Write a table with five semantic colors, their use, and the icon that accompanies each.

Sources

• W3C: Understanding Success Criterion 1.4.1: Use of Color
• W3C: Understanding Success Criterion 1.4.3: Contrast (Minimum)
• W3C: Understanding Success Criterion 1.4.11: Non-text Contrast
• National Eye Institute: Color Blindness