Don't Let Color Carry Meaning Alone on Service Pages
Red for errors, green for included, a colored word for a link: service pages often let color carry meaning on its own. WCAG's Use of Color criterion and research on color vision deficiency explain why that fails some visitors, and how to pair color with text, shape, or position instead.
A pricing table on a service site shows three packages. Included features have a green dot, excluded ones a red dot. To most visitors the table reads instantly. To a visitor who can’t tell those two colors apart, every row looks the same, and the main thing the table was built to communicate is gone.
This article explains WCAG’s Use of Color requirement, what research on color vision deficiency says about how many visitors are affected, and where service sites most often rely on color alone. It closes with a straightforward method for checking and fixing those places without giving up color as a design tool.
Why color alone fails some visitors
Designers use color to say things: this field has an error, this plan includes support, this word is a link, this time slot is taken. The trouble is that color is the one signal not everyone receives the same way.
Color vision deficiency, often called color blindness, means a person sees colors differently from most people. The U.S. National Eye Institute (NEI) describes it as usually inherited, and notes that the most common type makes it hard to tell red from green. Red and green are, of course, the two colors interfaces most often use for “wrong” and “right.”
How common is it? In a 2012 review in the Journal of the Optical Society of America A, Jennifer Birch of City, University of London summarized large population surveys. Inherited red-green deficiency affects about 8% of men and about 0.4% of women of European Caucasian descent, and between 4% and 6.5% of men of Chinese and Japanese ethnicity. Prevalence varies by population, so these figures don’t translate directly to any particular site’s audience. They do show that this isn’t a rare edge case: on a site with a substantial share of male visitors, several in every hundred may have trouble separating red from green.
Two qualifications matter. NEI notes that most people with color vision deficiency don’t have problems with everyday activities, which is part of why the issue goes unnoticed in design reviews. And color perception is not the only factor. Low vision, a dim phone screen in sunlight, or a grayscale printout can remove the same information for visitors with typical color vision.
What WCAG’s Use of Color criterion requires
The Web Content Accessibility Guidelines (WCAG) address this in Success Criterion 1.4.1, Use of Color, at Level A, the baseline level. It says color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
W3C’s explanation of the criterion gives examples that could have come from a service site: “required fields are red” and “error is shown in red.” It also states that the criterion should not discourage color coding, as long as another visual indication goes with it.
The lightness exception, and where it stops
The Understanding document makes a useful distinction. If two colors differ in lightness as well as hue, with a contrast ratio of at least 3:1 between them, the difference in lightness counts as an additional visual cue. A light green and a dark red could pass on that basis.
That exception has a firm limit. If the visitor needs to identify a particular color to understand the content, such as knowing that a green outline means valid and a red one means invalid, an extra indicator is required regardless of contrast. Knowing that two things are different isn’t the same as knowing which one means what.
Links in body text
Links are the most common place this criterion comes up. W3C Technique G183 covers inline links that are distinguished from surrounding text by color alone, with no underline: the link color needs a contrast ratio of at least 3:1 against the surrounding text, while both colors must still meet text contrast requirements against the background. Meeting all three at once can be hard, which is why an underline is often the simplest answer.
One further boundary: 1.4.1 concerns sighted users who can’t distinguish some colors. How the same information reaches screen reader users is handled by other criteria, so a fix for one group doesn’t automatically cover the other.
Where service sites rely on color alone
Platform design guidance arrives at the same rule. Apple’s Human Interface Guidelines advise against relying solely on color to differentiate objects, indicate interactivity, or communicate essential information, and suggest text labels or glyph shapes as alternatives. The guidelines add a reminder that color meanings vary by culture: red signals danger in some cultures and has positive associations in others.
On service websites, the same handful of patterns cause most problems:
| Pattern | Color-only version | Version with a second cue |
|---|---|---|
| Pricing or package table | Green and red dots for included and excluded | Check mark and dash icons, plus “Included” and “Not included” text for screen readers |
| Form errors | Field border turns red | Red border plus an error icon and a message naming the problem |
| Required fields | Labels shown in red | “(required)” in the label text, or a marked asterisk explained at the top of the form |
| Inline links | Link text in brand color only | Underlined links, or a 3:1 lightness difference from body text |
| Booking or availability calendar | Booked slots gray, open slots green | Booked slots struck through or labeled “Full” |
| Case study charts | Lines distinguished only by hue | Direct labels on each line, or different line styles and markers |
| Status badges | Colored pills with no wording | Pills that include the status word, such as “Open” or “Waitlist” |
A traffic light offers a useful comparison. Drivers who can’t tell red from green can still read it, because the stop signal sits in a consistent position. Position does the work that hue can’t. Web interfaces rarely have a fixed position to rely on, so they need a different second cue: text, shape, or pattern.
“If a design only works in color, it only works for some of the people looking at it.”
— Windware Studio Practice Note
A method for checking and fixing color use
The work is mostly inspection, and it fits naturally into a design review or a redesign audit.
Step 1: List every place color carries meaning
Go through key templates, such as the homepage, service pages, pricing, contact form, and booking flow, and note every place where a color means something. Include states that only appear after interaction: errors, success messages, selected options, and disabled buttons.
Step 2: Remove the color and look again
View each page in grayscale, either with an operating system setting or a browser extension. Chrome’s developer tools can also emulate several types of color vision deficiency. If a meaning disappears when color does, that element needs a second cue. These views are approximations of how a page may appear, not a replacement for feedback from people with color vision deficiency.
Step 3: Add the second cue that fits
- Status and inclusion are shown with text or a distinct icon shape, not only a colored dot.
- Error states include an icon and a written message, not only a red border.
- Required fields are marked in the label text.
- Inline links are underlined, or meet a 3:1 contrast ratio against body text and still meet text contrast against the background.
- Charts have direct labels or distinct line styles and markers.
- Any icon that carries meaning also has an accessible name for screen reader users.
What this costs, and what it doesn’t
The tradeoff is modest but real. Adding labels and icons uses space, and a pricing table with words in every cell is busier than one with dots. In most cases the extra text is short, and it often helps every visitor, because a word like “Included” is faster to read than a color key. The larger risk lies in the other direction: a carefully designed comparison that some visitors can’t read at all.
Practical takeaways for your next website
- Audit meaning, not palette. The question isn’t whether your colors look good together but whether any of them carries information on its own.
- Pair every meaningful color with a second cue. Text is the most reliable, followed by distinct shapes and patterns.
- Underline body-text links by default. It’s the simplest way to meet the requirement and the easiest for visitors to recognize.
- Check states, not just static pages. Errors, selections, and availability often rely on color in ways a screenshot of the default state won’t show.
- Keep using color. WCAG doesn’t ask for less color, only for color that isn’t working alone.
Ready to Discuss Your Website?
If you are planning a new website, a service redesign, or custom development for your business, we’re here to help you design pages whose meaning holds up for every visitor, whatever colors they see.
- Explore Our Services: Web Design · Web Development · Website Redesign
- Start a Conversation: Tell us about your project via our Contact Form or email us directly at
[email protected].