Why color matters

1. Four jobs for one channel

Take any page you used today and drain the color out of it, in your mind or with your system's grayscale setting. The words are still there and the layout is still there, but some things got harder: finding the button that matters, telling which tab is selected, noticing the error, recognizing whose site it is. Those are the things color was doing. On most pages it does four jobs at once.

• Identity. A brand color says whose page this is before the logo is read. Many brands are recognized by one hue, and a store's palette carries from its sign to its shopping bags to its web site. On the web, identity is also the reason designers care so much about getting one particular orange exactly right.
• Hierarchy. Color, mostly through contrast, tells the reader where to look and in what order. The primary action is the most saturated thing in its area; secondary actions are quieter; fine print is lighter. Color also marks the paths through a site (links, navigation, the current page) and groups things that belong together, such as all the controls of one form or the bars of one series in a chart.
• State. Color reports what is happening: an error, a success, a warning, the selected item, the visited link, the disabled button, the item that is on sale or sold out. This is the job with the most at stake, because a reader who misses a state makes a mistake.
• Mood. Color sets a tone. Warm and saturated reads as energetic or urgent; muted and cool reads as calm or serious; a black page with one bright accent reads as premium. What a color means also depends on who is reading, which page 09, Color across cultures, takes up: red is danger in one place, luck in another, and a rising stock price in a third.

Two more jobs grow out of these. Data encoding uses color to tell series, categories or magnitudes apart in a chart or a map, which is state and grouping at scale. Wayfinding uses consistent color for consistent purpose: if every link on a site is the same blue, a reader learns the rule once and uses it everywhere. That consistency is the reason the web's oldest color convention, blue links that turn purple once visited, still works decades after it began; page 02, How color works, tells its history.

Notice that each job can be done in other ways. Hierarchy can come from size, weight and position, as the Fonts section's Why type matters showed. State can be a word, an icon or a shape. Identity can be a logo and a name. Color is the fastest of these channels, the one the eye picks up before reading, which is why designers lean on it. It is also the least reliable one, which is why a page should never lean on it alone.

2. The unreliable channel

When a style sheet says background: oklch(55% 0.147 45), it is making a proposal. A designer chose that orange on a calibrated monitor in a dim studio, and the CSS records the choice precisely. Between the style sheet and the reader's brain, four things get a say, and any of them can change what arrives.

The screen

Screens differ more than most developers assume. A recent phone or laptop shows the wider Display P3 gamut, with more saturated reds and greens than the sRGB standard the web assumed for decades, while an office monitor or an older laptop may show sRGB or less. Few screens are calibrated; most ship tuned to look vivid in a store. Brightness is set by the reader, or by a sensor, or by a battery saver. Some panels shift color when seen from an angle. The same orange can be vivid on one device, flat on another and slightly brown on a third. Page 07, Displays and environments, covers gamut, wide-color and high-dynamic-range screens, and how a page can ask what the screen can do.

The room

Light in the room adds to light from the screen. In sunlight a phone's dark text and light background both get the same glare added, so the difference between them shrinks: contrast that was comfortable indoors becomes hard work at a bus stop. A projector is worse, because a projected "black" is only as dark as the screen in a lit room, and most projectors are dimmer and less saturated than any laptop. In a dark bedroom the opposite happens: a bright white page is glaring, which is one reason readers choose dark mode.

The eye

Readers' eyes differ too. The US National Eye Institute puts color vision deficiency at about 1 in 12 men, with far fewer women affected, and the most common kind makes red and green hard to tell apart. In a course of a few hundred students, that is very likely some of the people in the room. The lens of the eye yellows and lets in less light with age, so older readers see less contrast and have more trouble with blues. Readers with low vision need more contrast than the minimum, and everyone's eyes do worse when tired, distracted or moving. Page 08, Color for people, treats each of these, and the WCAG contrast rules built around them.

The settings

Last, and increasingly, the reader decides. Operating systems and browsers let a reader choose a dark appearance, which a page can follow; a forced colors mode, such as a Windows contrast theme, in which the system replaces the page's colors with the reader's own small palette; grayscale and color filters in the accessibility settings of phones and desktops; a warmer "night" tint in the evening; a reader view that strips the page's styles; and printing, where browsers leave background colors out by default. Firefox can also override every page's colors with the reader's own choices. Each of these exists because some readers need it, and each is a reason that the author's color is a proposal, not a promise. Type for people makes the same argument for fonts and sizes: the reader's settings win.

3. One card, five viewers

The demo below takes one Terra Outfitters product card, with a sale badge, a stock line and a sold-out size, and draws it five times. The first is the card as designed. The other four are what some readers get: a reader with deuteranopia, a reader with a grayscale display setting or a grayscale printout, a reader in bright sun, and a reader using forced colors. Under each card the demo computes the WCAG contrast ratio of each text and background pair as that reader gets it.

How each view is made

Each view is a simulation, and each is honest about being one.

• Deuteranopia, approximated. An SVG feColorMatrix filter multiplies every pixel's red, green and blue by a 3 × 3 matrix. The matrix is the severity 1.0 deuteranomaly matrix from Machado, Oliveira and Fernandes, "A Physiologically-based Model for Simulation of Color Vision Deficiency" (IEEE Transactions on Visualization and Computer Graphics, 2009), the model behind the vision-deficiency simulations in the developer tools of Chrome and Firefox. It describes an average; real color vision varies from person to person, and no filter shows exactly what one reader sees.
• Grayscale. filter: grayscale(1) keeps each pixel's luma and drops its hue, which is what a grayscale accessibility setting, an e-ink screen or a black-and-white printout does, more or less. It is also a quick test of hierarchy: if the important thing no longer stands out in gray, it stood out by hue alone.
• Sunlight, roughly. filter: contrast(0.6) brightness(1.3) squeezes every color toward the middle and lifts it, the way glare adds light to both text and background. It is a rough simulation, not a model of any real screen or sky, and the outline of the effect is what matters: pairs with little margin fail first.
• Forced colors, sketched. The fifth card swaps the card's tokens for system colors (Canvas, CanvasText, ButtonFace, ButtonText, GrayText), the same substitution a browser makes in forced colors. The sale badge's background and the stock dots disappear; a transparent border on the badge and the button becomes visible, which is a common trick for exactly this case. Your own browser in forced colors is the real test.

The demo computes its ratios with the same math the filters use: Machado's matrix on linear-light values, the grayscale luma weights 0.2126, 0.7152 and 0.0722 on the encoded values, and the contrast and brightness formulas from the Filter Effects specification. Those formulas were checked against the pixels Chrome draws for the same filters, and they match to the unit. That is the habit this section asks for: when a page says a pair has a contrast of 5.1:1, the number was computed, not guessed.

The lesson of the demo is in what does not change. All five cards still say "Sale", "In stock" and "Sold out", still show a check and a cross, still strike through the sold-out size and still outline the size buttons. A reader can shop from any of them. Delete the words and the icons, keep only the colored dots, and the second, third and fifth cards stop working. That is the rule of section 5.

4. What the numbers say

Every year since 2019, WebAIM, an accessibility organization based at Utah State University, has run its WAVE accessibility checker over the home pages of the top million web sites and published the results as the WebAIM Million. The 2026 report, the eighth, from pages collected in February 2026, found detectable WCAG 2 failures on 95.9 percent of home pages, with an average of 56.1 errors per page. The single most frequent failure was low-contrast text:

The 2026 report found low-contrast text on 83.9 percent of home pages, up from 79.1 percent in the 2025 report, and an average of 34 distinct instances of low-contrast text per page, up 15 percent from 2025. Low contrast has topped the report's list of failure types every year since 2019.

Read those numbers carefully, because the report does. Low contrast is the most commonly detected failure, which is not quite the same as the most common one. A contrast ratio is easy for a program to check: it reads the text color and the background color and does the arithmetic. Many other failures are hard or impossible to detect automatically: whether alternative text is accurate, whether a page can be used with a keyboard, whether an error message makes sense. WebAIM says so directly: "not all conformance failures can be automatically detected," and the absence of detected errors "does not indicate that a page is accessible." So the true failure rate for the web is higher than the report's figure, and contrast tops the list partly because it is so easy to find.

That cuts both ways for a developer. Contrast is the failure most likely to be in your own work, and it is also the easiest to catch: the same arithmetic runs in browser developer tools, in linters and in a test suite. This site's own theme is checked that way on every test run, as Color in CSS describes.

What WCAG asks

The Web Content Accessibility Guidelines, WCAG 2.2, have three success criteria about color at levels A and AA, and every page in this section returns to them (a fourth, 1.4.6 Contrast (Enhanced), asks for 7:1 at level AAA):

• 1.4.1 Use of Color (level A): color is not the only visual means of conveying information, indicating an action, prompting a response or distinguishing an element. This is the redundancy rule.
• 1.4.3 Contrast (Minimum) (level AA): text has a contrast ratio of at least 4.5:1 with its background, or 3:1 for large text.
• 1.4.11 Non-text Contrast (level AA): the parts of controls and graphics needed to understand them, such as a text field's border, a focus ring or a chart's lines, have at least 3:1 against what is next to them.

The contrast ratio runs from 1:1, the same color, to 21:1, black on white. It is computed from relative luminance, how much light a color sends to the eye, which Color in CSS measures and How color works explains; page 08 covers the ratio's known limits. For now, the number to remember is 4.5:1 for ordinary text, and the habit to build is to treat it as a floor with margin above it, because the room and the screen take some away. The sunlight card in the demo shows why: the pair that passed at 4.7:1 failed first.

5. Redundancy: color plus one more cue

If color is unreliable, the answer is not to stop using it. Color is fast, it is pleasant, and it helps most readers most of the time. The answer is redundancy: color reinforces a message and never carries it alone. Every state on a page is said at least twice, once in color and once in something that survives without it: a word, an icon, a shape, a pattern, an underline, a position or a size.

The usual failure looks reasonable in a mockup. Here is stock shown by a colored dot, which is the inaccessible store's SIN #8:

To a reader with red-green color deficiency the dots are the same; to a screen reader they are nothing at all; in forced colors their backgrounds vanish. The fix says the state in words, and lets color repeat it:

The same pattern applies everywhere color reports something:

• Links keep their underline in body text, so they are found by shape as well as by color. Links people can use covers when an underline can go.
• Form errors are words next to the field, tied to it in code, with an icon; a red border is the reinforcement. Forms people can use shows how.
• Charts label their series directly, and tell lines apart by pattern or marker as well as hue.
• Selected and current items get a shape change, such as a heavier border, a check or an indicator bar, as well as a color change.
• Focus is a visible ring, not a faint shift in color.

A quick test catches most problems: look at the page in grayscale. Most operating systems have a grayscale setting, and filter: grayscale(1) on the root element in developer tools does the same. If something that matters disappears, it was carried by hue alone. Redundancy is also what makes the reader's settings safe to honor. A page that says everything twice can let the reader's palette replace its own, and nothing is lost.

6. The running example: a store with ten color sins

The section's running example is the Terra Outfitters store, which earlier lessons broke in other ways. For Color it has a new page, a seasonal sale page called the Trail report, in two copies. The discolored Trail report chooses its colors the way many sites do: by eye, in hex and HSL, on one light screen. Its source numbers ten sins, SIN #1 to SIN #10. The fixed Trail report has the same content, word for word, and marks each repair as COLOR FIX #n with the same number. Open both and view their source.

This page does not fix any of them; it introduces them. Three are already visible in what you have read. SIN #5, #8 and #9 are failures of redundancy: a chart, an error and a link that each say something only in color, exactly what the one-card demo shows breaking. SIN #7 is a contrast failure of the kind WebAIM counts: white words over a pale evening sky, comfortable in the mockup, which used a darker photo, and 1.8:1 to 2.8:1 on the real one, by the source's own measure. SIN #10 is mood and meaning: a color that says "good news" to one reader says "bad news" to another.

The others are about how colors are written rather than what they look like, and they matter for a different reason. A hover color picked by eye works today and drifts tomorrow, when the brand color changes and nobody remembers which hex values to update. A palette in HSL looks orderly in the code and uneven on the screen. A dark mode made by inverting everything is one line of CSS, and it turns the product photos into negatives. These are maintenance failures, and they are the reason this section asks you to write colors as tokens.

Three color problems are not on the list because the store's inaccessible copy already has them: low-contrast body text (its SIN #7a), stock shown by a colored dot (SIN #8, the bad sample above) and a removed focus outline (SIN #4a). The Color pages link there for those.

7. The developer as the bridge

On most teams, someone else chooses the colors. A designer builds a palette in a design tool, tries it on a mockup, and hands over a set of swatches, usually as hex values with names such as "Brand Orange" or "Gray 400". The developer turns those swatches into CSS that runs on every reader's device. As with type in the Fonts section's Why type matters, the developer is the bridge between the two, and for color the bridge carries a particular load: the design tool showed each color once, on one screen, to one pair of eyes, and the page must work on all the screens, rooms, eyes and settings of section 2.

In practice that means a few habits, each of which has a page later in the section:

• Convert once, at the border. Turn each hex swatch into oklch() with a script, keeping the hex in a comment so anyone can trace it back to the design file. Color in CSS does this for this site's own theme.
• Name by role. Components use --accent, --surface and --danger, not "orange" and "gray-400". A role can change value in dark mode or forced colors; a hue name cannot. Choosing and pairing, page 05, builds a full token set.
• Derive, do not pick. Hover, active and disabled states come from the role token by rule, so a change to the brand carries through. That is page 04, Deriving color.
• State the contrast. Every text and background pair has a computed ratio, written down and tested.
• Plan for every condition. A dark version of every role (page 06), a fallback for screens that cannot show a wide-gamut color (page 07), a second cue for every state and a forced-colors check (page 08), and colors whose meaning travels (page 09).

Questions worth asking at handoff

Being a good bridge is partly asking the right questions before writing any CSS:

• What is each color for? Which are brand, which are surfaces and text, which report state?
• Which text goes on which background, and what is the contrast of each pair? Does the pale gray for hints still reach 4.5:1?
• What is the dark version of each color? Is there one?
• Besides color, how does each state show: error, success, selected, disabled, on sale, sold out?
• Were these colors seen on a phone outdoors, or a projector, or only on the design monitor?
• Do any colors carry meaning that changes by market, such as red and green for prices?

The bridge runs both ways. Designers learn from developers what the platform does with their colors: that the reader may replace them, that a vivid P3 color falls back on an older screen, that a gray which looked elegant fails a test. A developer who knows the vocabulary of color, from hue and chroma to gamut and luminance, can have that conversation as a peer, and the rest of this section supplies the vocabulary.

8. The road map for this section

The Color section has nine pages, meant to be read in order but usable on their own. They follow the course's ladder of qualities: what color is and how CSS writes it, then how to keep it maintainable and usable, then how it adapts to the screen, to the reader's needs and to the reader's culture.

1. Why color matters, this page: the four jobs, the unreliable channel, redundancy and the bridge.
2. How color works: light and perception, color models and color spaces, gamut, and a short history of web color, from sixteen names and the web-safe palette to oklch().
3. Color in CSS: every notation, reading oklch(), colors no screen can show, where color applies, currentColor, reading colors back and turning hex into tokens.
4. Deriving color: color-mix(), relative colors, contrast-color() and gradients interpolated in the right space.
5. Choosing and pairing: harmony, tonal scales, token sets and palettes for charts.
6. Light and dark: color-scheme, prefers-color-scheme, light-dark() and a theme switch that respects the system.
7. Displays and environments: sRGB, P3 and HDR, sunlight and projectors, print and grayscale.
8. Color for people: contrast, color vision deficiency, forced colors and focus.
9. Color across cultures: what colors mean, and to whom.

The section hints at the color science underneath without becoming a course in it. A color on screen is light from three kinds of tiny emitters, measured against a model of three kinds of cones in the eye; converting between spaces is a few matrix multiplications; fitting a color into a screen's gamut is a search. You will meet each of these where it explains something you can see, and the hub's How these pages use color lists the house rules every demo follows.

9. Summary