Picture a contact form. A field filled in incorrectly turns red. A valid field turns green. Clean, intuitive, elegant — for most of your visitors.
The problem is that roughly 8% of men and 0.5% of women can’t reliably tell that red from that green. Worldwide, that’s close to 300 million people. If the only signal that “something is wrong” is a color a portion of your audience literally cannot see, you don’t have an elegant form. You have a form that quietly fails one in twelve men who try to use it.
Here’s why that should get your attention beyond good manners: on both sides of the Atlantic, this exact category of problem — color and contrast — now carries legal weight. In the United States, insufficient color contrast is one of the most-cited issues in a record wave of accessibility lawsuits, and low-contrast text is the single most common accessibility failure on the web, present on nearly 80% of homepages (WebAIM Million, 2025). In the European Union, the same requirements became enforceable in 2025.
So this isn’t a “nice to have.” It’s design, UX, and — increasingly — legal exposure, all pointing in the same direction. Let’s unpack it properly, because the common advice (“don’t use red and green”) is repeated thoughtlessly and is often simply wrong.
Why red and green is the classic trap
The most common form of color vision deficiency — deuteranopia and protanopia — makes it hard to distinguish reds from greens. It is not black-and-white vision, as many assume. Someone with this condition sees color; certain colors just collapse into one another in ways a fully-sighted designer won’t predict intuitively.
But — and this is the nuance most guides skip — red and green side by side aren’t always a problem. Color only becomes a problem when it’s the sole carrier of meaning.
If a red line and a green line on a chart sit apart, are labeled, or differ in position and shape, the user will understand them even if both colors blur into a single muddy brown. Context, position, and labeling carry the information independently of hue. The design only breaks when the only difference between “success” and “error” is the color itself.
That distinction matters, because it lets you design sensibly instead of dogmatically. You don’t have to ban red and green from your palette. You have to make sure meaning never rests on them alone.
It’s not just red and green
Fixating on one color pair breeds false confidence. For people with stronger color vision deficiency, the problem is wider: red, green, brown, and orange can all merge into a single indeterminate brown. “Avoid red and green” is too narrow a rule.
Worse, there are pairs nobody thinks about that cause exactly the same trouble:
- Blue and purple. Purple is, roughly, blue with red mixed in. Someone who “loses” the red component sees purple almost identically to pure blue.
- Pink and gray. Pink is lightened red — under red-green deficiency it can flatten into gray.
- Gray and brown. Another pair that regularly merges.
The takeaway is simple: you can’t memorize a blacklist of “forbidden” pairs and be done. Instead of learning what to avoid, adopt one overriding principle (coming up shortly) and test real designs in a simulator.
The secret nobody mentions: hue vs. lightness
This is the most practical piece of knowledge in the whole topic, and the least often repeated.
Color vision deficiency affects hue, not lightness (value). In plain terms: someone who can’t tell red from green can easily tell a very light color from a very dark one.
That opens a door. If you must use red and green together — say they’re brand colors, or an entrenched convention — make them differ sharply in lightness. Light green and dark red will work, because to a color-deficient eye they become a de facto “lighter–darker” scale, and everyone can read that.
The same principle applies to interface states, chart series, and heatmaps. When you differentiate elements by lightness as well as hue, the design becomes resistant to color blindness almost as a side effect.
What WCAG actually requires
The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility — and, as we’ll see, the common technical yardstick behind the law in both the US and the EU. Two rules matter most here.
First — color cannot be the only means of conveying information (criterion 1.4.1). This is the same idea running through this whole article, stated formally. Status, action, warning — all must be recognizable without color: through an icon, a label, a pattern, an underline.
Second — contrast. At Level AA, WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text and interface elements. Level AAA goes higher (7:1), but AA is what most projects target and what the legal landscape effectively expects.
There are a few deliberate exceptions worth knowing, because they come up in almost every client conversation. Large text gets the lower 3:1 bar, as noted. Incidental text — anything inactive, purely decorative, or part of an image that isn’t the point of the content — is exempt. And logotypes are exempt entirely: text that’s part of a brand name or logo has no contrast requirement at all. So if a client’s existing logo doesn’t “pass,” that’s fine — the rule was never meant to apply to it. Everything a user actually needs to read or act on, though, is in scope.
Contrast is not an aesthetic preference. Light-gray text on white can look modern in a design file and be unreadable on a phone in sunlight — for everyone, not just people with a vision impairment. Good accessibility is simply good UX with a safety margin. It’s also, as the lawsuit data shows, the fastest way to end up on a plaintiff’s list.
Choose the right palette type for your data
Before you pick specific colors, it helps to know which kind of palette you actually need. This distinction prevents a lot of mistakes — especially on dashboards and charts, which increasingly live on client websites. Palettes come in three types:
- Sequential — one hue running from light to dark. For data with natural order and magnitude: traffic volume, temperature, sales levels. Lightness itself carries the information, so a sequential palette is resistant to color blindness almost by definition.
- Categorical — several distinctly different hues. For categories with no inherent order: company departments, traffic sources, product types. This is where the color-blindness trap waits, because you’re relying purely on hue difference — keep the number of categories low and add labels.
- Divergent — two colors spreading out from a neutral middle. For deviations from a reference point: profit vs. loss, above/below target, gain/decline.
Divergent palettes are precisely where people reach reflexively for red and green — and precisely where the hue-vs-lightness rule earns its keep. If your two poles need to differ by more than hue, give them a clear lightness difference and keep the midpoint genuinely neutral.
The legal reality: two markets, one standard
For years, digital accessibility in the private sector was treated as optional. That era is over — and if you serve customers in the US or the EU, the pressure now comes from both directions at once. The good news: both regimes converge on the same technical yardstick, WCAG 2.1 Level AA, so one accessible build satisfies both.
United States: a record wave of lawsuits
Accessibility litigation in the US hit a record in 2025. More than 5,000 digital accessibility lawsuits were filed across federal and state courts (UsableNet), continuing a climb that has run every year since 2017. A few realities worth knowing:
- It’s not just big brands. Small and mid-sized companies make up the majority of defendants, and serial filers pursue them systematically. Nearly half of federal cases in 2025 targeted companies that had already been sued at least once.
- E-commerce and food service are prime targets. Transaction-heavy sites draw the most claims — e-commerce alone accounted for around 70% of ADA digital cases, with food service a distant but notable second. If a website lets someone browse, book, order, or check out, a barrier there is a barrier to a transaction.
- The Domino’s precedent still governs. Courts have reinforced that a website or app tied to a physical business falls under the ADA. For most service businesses, digital accessibility is no longer arguable.
- Overlay widgets don’t save you. “One-click compliance” tools are not a defense — around a third of 2025 lawsuits targeted sites that already had an overlay installed, and in 2025 the FTC fined one major overlay vendor $1 million for marketing its product as guaranteed ADA compliance. Real compliance is code-level, not a widget.
- WCAG 2.1 AA is the practical standard. There’s no explicit federal rule for private commercial websites under ADA Title III — cases proceed directly under the statute — but plaintiffs, settlements, and the DOJ’s Title II rule for government all converge on WCAG 2.1 AA.
Europe: the EAA, “the next GDPR”
The European Accessibility Act (EAA, Directive 2019/882) became enforceable on 28 June 2025 across all 27 EU member states. Unlike earlier rules that covered only the public sector, it reaches private business: e-commerce, banking, telecommunications, transport, and a range of digital services. What to know:
- Who it covers. Anyone selling goods or services to consumers in the EU — regardless of where the company is based. A US business selling into Europe is in scope.
- Microenterprise exemption. Companies with fewer than 10 employees and annual turnover or balance sheet under €2M are exempt from parts of it. Plan ahead, though — that threshold is easy to cross.
- Penalties are real. Each member state sets its own. In Germany they reach €100,000 per violation, and its competition-law regime lets private law firms send warning letters on top of that.
- Enforcement has started. In France, disability organizations sent formal notices to major retailers in mid-2025 and filed the first EAA lawsuits in late 2025. Sweden and the Netherlands have begun inspections and information requests — including to companies based outside the EU.
- The standard is WCAG 2.1 AA, via the harmonized norm EN 301 549. Many are calling the EAA “the next GDPR” for exactly this reason: broad reach, real teeth, global spillover.
The through-line is simple. Whether your customers are in New York or Nice, the target is the same, and the cheapest time to hit it is before someone else raises the issue for you.
Five practical rules for color-accessible design
Everything above reduces to a handful of habits you can build into your day-to-day process.
1. Never encode information with color alone. This is the overriding rule. Pair every meaning with a second signal: an icon (an “X” on an error, a lock, a checkmark), a text label, a pattern, or a shape. If the design still makes sense with the color stripped out, it’s accessible.
2. Check contrast — measure, don’t eyeball. Visual judgment is unreliable; it varies by monitor, device, and lighting. Use a tool: WebAIM Contrast Checker, the built-in checker in Chrome DevTools, or TPGi’s desktop Colour Contrast Analyser (which samples colors straight off the screen). Target at least 4.5:1 for text. Remember: low contrast is the single most-cited failure in accessibility complaints.
3. Choose palettes that survive color vision deficiency. The classic safe pair is blue and orange — blue stays blue under most deficiencies. When building a palette, Adobe Color (its accessibility tab flags which colors will merge), WhoCanUse (which tells you how many users a combination affects), and Viz Palette by Susie Lu and Elijah Meeks (which tests a whole palette across all deficiency types and shows a grayscale preview) all help.
4. Design states to be recognizable without color. Hover, focus, active, error, disabled — each should differ by more than hue: a border, a shadow, an icon, an underline, a lightness shift. The focus state matters especially for people navigating by keyboard.
5. Test in simulators and real conditions. Chrome DevTools has built-in vision-deficiency emulation (Rendering → Emulate vision deficiencies) — you can view your own site as someone with protanopia or deuteranopia would, without leaving the browser. For images and palettes, Coblis or Sim Daltonism (macOS) work well. For a full audit, use axe DevTools and Lighthouse. The simplest robustness test of all is grayscale: strip the color out and check whether elements still differ. If they do, the design will survive not just color blindness but also black-and-white printing, a cheap monitor, or a screen in full sun. No automated tool replaces testing with a real user — if you can, do it.
How we approach accessibility at Less Code
Our principle is straightforward: we build accessibility in from the first sketch rather than bolting it on as a patch before launch. That difference isn’t only about quality — it’s about cost. Remediating a finished, inaccessible site is often more expensive than designing it correctly the first time, and, in the current climate, far cheaper than a demand letter.
In practice, that means choosing a color-vision-resistant palette during branding, verifying contrast while the interface is being designed rather than after, and auditing WCAG conformance before a project ships. Because the US and EU both point at WCAG 2.1 AA, a single accessible build serves clients on both sides of the Atlantic — whether the pressure comes from an ADA plaintiff or an EAA regulator.
The bottom line
Accessible design isn’t a concession to a minority. It’s simply better design — clearer in sunlight, on a cheap monitor, for a tired pair of eyes, for everyone. “Don’t use red and green” is just the tip of it. The real rule is: don’t make users rely on one sense where you can give them two.
And in 2025 and beyond, if you do business online in the US or Europe, it’s also a matter of staying off a plaintiff’s list.
A good first step? Open your own site in Chrome DevTools, turn on vision-deficiency emulation, and see what’s left of your messaging once the color disappears. Ten minutes there will tell you more than most audits.
