Relying on colour alone breaks accessibility for a lot of people. Here's how to fix that fast without a full redesign.

Relying on colour alone is one of the most common accessibility fails I see, and it affects more people than you might think. Around 8% of men and 0.5% of women have some form of colour vision deficiency, and that’s before considering users with low vision, those using high contrast modes, or anyone viewing your site in bright sunlight where colours wash out.

The good news? It’s an easy fix that makes your interface clearer for everyone, not just those with accessibility needs. Whether it’s form errors, buttons, or active states, here are three quick ways to make your UI work without relying on colour as the only signal.

---

1. Add Text or Icons to Error States

Bad:

<p class="text-red-600">Password is required</p>

Why it fails: If someone’s colour blind or using a greyscale screen, that red text conveys no meaning. Screen readers also can’t communicate the urgency or importance of the message without additional semantic cues.

Better (for dynamic errors):

<p class="text-red-600" role="alert" aria-live="assertive">
  <span aria-hidden="true">❌</span>
  <span>Password is required</span>
</p>

This approach works because it adds a clear visual symbol that’s universally understood, uses role="alert" to tell assistive technology this is important information that should be announced immediately, and includes aria-live="assertive" so screen readers interrupt what they’re doing to announce the error when it appears.

For static errors that are visible when the page loads, use a different approach:

<input id="password" aria-describedby="pwd-error">
<p id="pwd-error" class="text-red-600">
  <span aria-hidden="true">❌</span>
  <span>Password is required</span>
</p>

Here, aria-describedby creates a relationship between the input and error message, so screen readers announce the error when the user focuses on the field.

---

2. Use Underlines or Style Shifts for Hover States

Bad:

a:hover {
  color: #007acc;
}

Better:

a:hover {
  color: #007acc;
  text-decoration: underline;
}

Or add a visual indicator:

a:hover::after {
  content: " ↗";
}

For non-link elements, consider alternatives that won’t confuse users:

.button:hover,
.button:focus-visible {
  outline: 4px solid #ffbf47;
  border-color: #000;
}

.button {
  padding: 8px 16px;
  border: 2px solid #ccc;
  border-radius: 4px;
}

The key is that any change in shape, added icon, border, or text style provides a visual cue that doesn’t depend on colour perception. Users can immediately see that something’s changed when they hover, regardless of how they perceive colour.

---

3. Make Selected States Clear Without Colour

Let’s say you’ve got a set of toggle buttons for switching between view modes.

Bad:

.button1.active {
  background: #2ecc71;
}

Better approach:

<button class="button2 active" aria-pressed="true">
  Grid view
</button>

.button2.active {
  background: #2ecc71;
  font-weight: bold;
}

.button2.active::before {
  content: "✔ ";
}

This works because it combines multiple signals: a visible checkmark that’s clear in any colour context, aria-pressed="true" to communicate the toggle state to screen readers (true means pressed/active, false means not pressed), and a font weight change that adds another visual differentiation layer.

Why this matters: This approach follows WCAG Success Criterion 1.4.1 (Use of Color), ensuring your interface works for the roughly 300 million people worldwide with colour vision deficiency.

---

Test Your Work

The simplest way to check if your interface works without colour is to view it in greyscale. Here’s how:

In Chrome DevTools:

1. Right-click → Inspect (or F12)
2. Click the three dots menu → More Tools → Rendering
3. Under “Emulate vision deficiencies”, select “Blurred vision” or “Protanopia”

---

Browser Extensions such as Silktide’s Accessibility Checker test for colour contrast and other accessibility issues…

If you can still understand what’s interactive, what’s selected, and what’s gone wrong in greyscale, you’re on the right track.

Ask yourself: if all the colour vanished from your site tomorrow, could users still work out what’s going on? If the answer’s no, it’s time to back up those colour cues with something more reliable.

Try these examples in Chrome DevTools’ greyscale mode to see why the “better” versions work!