WCAG 1.4.1 · Level A · EN 301 549 9.1.4.1

Use of Color

Requires that color is not the only way to convey information, show an action or tell elements apart, so people who cannot see color still get the meaning.

In brief

About one in twelve men and one in two hundred women have a color vision difference. Many more people use a screen in bright light, in grayscale or with a high contrast mode, and blind users cannot see color at all. If color is the only thing that tells them something, they miss it.

This criterion requires that color is not the only visual means of conveying information, indicating an action, prompting a response or distinguishing a visual element. Color can still be used, as long as another cue, such as text, a shape, a pattern or an underline, carries the same meaning.

What does it cover?

  • Links in text: A link inside a paragraph must be distinguishable from the surrounding text by more than its color alone, for example an underline.
  • Form errors and required fields: A red border or a red label is not enough. Add text, an icon or a symbol.
  • Charts and maps: Lines, bars and map areas that differ only by color need labels, patterns or markers.
  • Status and state: Colors that show success, warning, offline or selected must also be shown with text or an icon.
  • Instructions: Telling people to "press the green button" is covered together with 1.3.3 (Sensory Characteristics).
  • Out of scope: The contrast of text is covered by 1.4.3, the contrast of icons and component borders by 1.4.11, and the information that a screen reader announces by 1.3.1.

Who does it affect?

People with color vision differences cannot tell some colors apart. Blind users get no information from color. People with low vision, people who use a screen in strong light, people who use grayscale, high contrast or forced colors modes, and people who print in black and white also lose color cues. Clear text and symbols help everyone, including people with cognitive differences.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Information that does not depend on color alone is part of "perceivable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 1.4.1 by reference and turns it into separate clauses for each kind of ICT.

Where WCAG 1.4.1 appears in EN 301 549
ClauseType of ICTWhat it requires
9.1.4.1Web pagesWeb content must satisfy WCAG success criterion 1.4.1.
10.1.4.1Non-web documents (PDF, Office files)The same criterion applies to documents, such as charts and highlighted text in a PDF.
11.1.4.1Non-web software (native mobile apps)Software that supports screen readers must satisfy the criterion.

Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 1.4.1 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Links inside text

A link in running text needs a cue other than color. An underline is the simplest one.

Incorrect
a { color: #0066cc; text-decoration: none; }
Correct
a { color: #0066cc; text-decoration: underline; }

2. Form errors

Show the error in text, and connect it to the field. Color and an icon can support it.

Incorrect
<label for="email">Email</label>
<input id="email" style="border: 2px solid red">
Correct
<label for="email">Email</label>
<input id="email" aria-invalid="true"
       aria-describedby="email-error"
       style="border: 2px solid #c62828">
<p id="email-error" class="error">
  <span aria-hidden="true">⚠</span>
  Error: enter an email address, for example [email protected].
</p>

3. Required fields

Say that a field is required in its label.

Incorrect
<label for="name" style="color:red">Name</label>
<input id="name">
Correct
<label for="name">Name <span>(required)</span></label>
<input id="name" required>

4. Status

A colored dot alone does not say anything to a user who cannot see the color.

Incorrect
<span class="dot dot-green"></span>
Correct
<span class="dot dot-green" aria-hidden="true"></span>
<span>Online</span>

5. Charts

When lines or bars differ only by color, add direct labels or different markers and patterns.

Incorrect
<!-- Three lines, red, green and blue, with a color legend -->
<svg>…</svg>
Correct
<!-- Three lines with direct labels and different markers -->
<svg>
  <path d="…" stroke="#c62828" />
  <text x="300" y="40">Sales ●</text>
  <path d="…" stroke="#2e7d32" stroke-dasharray="6 4" />
  <text x="300" y="90">Costs ▲</text>
</svg>

6. Selected state

Mark the selected item with more than a color change, for example a bold weight, a check or an underline, and expose the state in code.

Incorrect
.tab { color: #666; }
.tab.active { color: #0066cc; }
Correct
.tab { color: #595959; }
.tab[aria-selected="true"] {
  color: #0b5fff;
  font-weight: 700;
  border-bottom: 3px solid currentColor;
}

Code examples for mobile

The same rule applies in native mobile apps. Pair every color with an icon or text, and make sure the accessibility label states the status too.

iOS (SwiftUI)

import SwiftUI

struct StatusRow: View {
    let online: Bool

    var body: some View {
        HStack(spacing: 8) {
            // Color + icon + text, not color alone
            Image(systemName: online ? "checkmark.circle.fill" : "xmark.circle.fill")
                .foregroundStyle(online ? .green : .red)
                .accessibilityHidden(true)

            Text(online ? "Online" : "Offline")
        }
        .accessibilityElement(children: .combine)
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Row
import androidx.compose.material.icons.Icons
import androidx.compose.material.icons.filled.CheckCircle
import androidx.compose.material.icons.filled.Cancel
import androidx.compose.material3.Icon
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.semantics.semantics

@Composable
fun StatusRow(online: Boolean) {
    // Color + icon + text, not color alone
    Row(modifier = Modifier.semantics(mergeDescendants = true) {}) {
        Icon(
            imageVector = if (online) Icons.Filled.CheckCircle else Icons.Filled.Cancel,
            contentDescription = null,
            tint = if (online) Color(0xFF2E7D32) else Color(0xFFC62828)
        )
        Text(if (online) "Online" else "Offline")
    }
}

How to test

  • View it in grayscale: Turn the page or the app to grayscale, or use the browser rendering emulation. Can you still tell links, errors, states and chart series apart?
  • Simulate color vision differences: Use the browser developer tools to emulate color blindness. Does any information disappear?
  • Look for color-only cues: Check links in text, form errors, required fields, status badges, selected tabs, charts, maps and legends.
  • Check the code: Is the information also present as text, an icon, a pattern or a programmatic state, such as aria-invalid and aria-selected?
  • Test with forced colors: Turn on high contrast or forced colors mode. Are states still visible?
  • Check mobile: Does each status in the app have an icon or text as well as a color, and does the screen reader announce it?
  • Use a checker as a start: Automated tools cannot tell whether color is the only cue. Only a person can decide that.

Common mistakes

  • Links without an underline: A link that only differs by color cannot be found by everyone.
  • Red borders as the only error cue: Add a message that says what is wrong.
  • A color legend with similar colors in a chart: Add direct labels, markers or patterns.
  • Status dots with no text: Green and red look alike to some users.
  • Marking the selected item only by color: Add a weight, check mark or underline.
  • Instructions such as "the green button": Name the button as well. See 1.3.3.
  • Using color for required fields only: Say "required" in the label.
  • Forgetting print and forced colors: Color cues disappear in black and white and in high contrast modes.

Sources

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.

Corpowid is recognized by Gartner

Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.