About 1 in 12 men and 1 in 200 women in the UK have some form of colour vision deficiency. That’s roughly 3 million people. And yet, I’d estimate that at least half the digital products I review have UI decisions that make life actively harder for those users. Red-on-green status badges. Light grey placeholder text on white. Gradient buttons where the text disappears on a cheap display. These are not edge cases. They’re just bad colour accessibility design, repeated across the industry at scale.
The frustrating part is that the tools to catch this have existed for years. WCAG 2.1 has been around since 2018. The Web Content Accessibility Guidelines spell out minimum contrast ratios in plain language. And still, product teams ship inaccessible palettes every single week. Let me walk through why, and what you can actually do about it.
The WCAG contrast ratios most teams get wrong
WCAG defines two levels of contrast compliance: Level AA and Level AAA. For normal text, AA requires a contrast ratio of at least 4.5:1. Large text (18pt or 14pt bold) drops to 3:1. AAA pushes normal text to 7:1. Most UK product teams aim for AA, which is reasonable, but they check it once during design handoff and never again after the developer has implemented the palette in code.
Here’s where it goes wrong. A designer checks the contrast ratio of dark blue text on a white background. Passes. Then a developer applies an opacity value to the same element, or the background becomes a card with a slightly off-white tint, or a hover state changes the background colour. Suddenly you’re at 3.2:1 and nobody’s noticed because nobody re-ran the check. Contrast is not a static property of a colour; it is a relationship between two colours in the exact context they appear.
I’d also flag that checking contrast ratio alone is not the same as designing for colour vision deficiency. A 4.5:1 ratio between red and green can technically pass a contrast checker while being completely indistinguishable to someone with deuteranopia (the most common form of red-green colour blindness). WCAG compliance and inclusive colour accessibility design are related, but they are not identical.
The four types of colour vision deficiency you actually need to design for
Deuteranopia and protanopia are both forms of red-green colour blindness, affecting the green-sensitive and red-sensitive cones respectively. Tritanopia affects blue-yellow perception and is much rarer. Achromatopsia (complete colour blindness) is rarer still. For most practical design decisions, deuteranopia and protanopia are where your palette choices will cause the most problems, and they often produce similar confusion: red, orange, yellow, and green all collapse toward a brownish-yellow or olive spectrum.
This matters enormously for specific design conventions. Traffic-light status systems (red bad, amber warning, green good) are genuinely problematic for a significant chunk of your users. If your SaaS dashboard uses colour alone to communicate status, you’ve already failed those users, regardless of what your contrast ratio is. The fix is not to abandon colour; it’s to never rely on colour as the only differentiator. Add an icon, a label, a pattern, a shape. Colour should reinforce the signal, not carry it alone.
Building an accessible colour palette from scratch
I tend to start palette work in Figma with a base neutral ramp (typically 10 shades from near-white to near-black), then layer in one primary colour and one or two accent colours. The constraint I impose from the start: every interactive element must read clearly when viewed through a deuteranopia simulation, and every text element must pass AA contrast against every background it might appear on.
A few practical rules I use:
Avoid pure red and pure green as paired status indicators. If you need two semantic colours for success and error states, try blue and orange, or blue and red. Blue is safe for almost all colour vision deficiencies. If your brand insists on green for success, pair it with a distinct shape or icon, not just a colour change.
Increase contrast beyond the minimum. 4.5:1 is the floor, not the target. I aim for 6:1 on body text as a working default. On interactive elements like buttons and form inputs, I want the border or outline to carry contrast independent of fill colour, so the element’s boundaries are clear even if the fill reads as a similar hue to the background for some users.
Test your palette in a simulator, not just your head. Figma has a built-in colour blindness simulator under View > Accessibility. Sketch and Adobe XD have similar options. I also regularly paste screenshots into Coblis or the browser extension Colorblindly to see how a full page reads. This is not optional. Your own colour perception is not a reliable test instrument.
Check states, not just default views. Hover states, focus rings, disabled states, error states, selected rows in a table. Each of these introduces a new colour context that needs its own accessibility check. This is where I see empty state UI design go wrong too: teams design the happy path accessibly and forget the edges.
Where UK product teams specifically trip up
The Government Digital Service accessibility guidelines are genuinely excellent, and GOV.UK itself is one of the better-performing large sites on colour accessibility. The problem is that outside of public sector work, most UK product teams treat accessibility as a compliance checkbox rather than a design constraint that applies from day one.
I see three recurring failure modes. First: palette inherited from a brand identity created by a print agency, where colour choices were made for CMYK output with no thought given to screen contrast. The brand colour is a soft teal on white, it looks lovely on a business card, and it reads at 2.8:1 on screen. Second: a dark mode implementation added after launch that nobody tested with a contrast tool at all. Third: teams that do check WCAG but only check the primary brand blue on white, then assume the rest of the palette is fine.
If your team is shipping anything that touches the public (and especially if it handles data, finance, or health information), you also have legal considerations. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require WCAG 2.1 AA compliance for public sector bodies. Private sector products are not yet legally mandated in the same way, but the UK government’s accessibility guidance is worth reading regardless of whether you’re building for the public sector, because it’s simply well-written practical advice.
For teams checking deliverability and technical health across their digital stack, tools like dijitul can surface issues that are easy to miss when you’re deep in the product work itself.
The semantic colour system approach
The most resilient approach I’ve seen for colour accessibility design is building a semantic token layer on top of your raw palette. Instead of using hex values directly in components, you reference tokens like --color-status-error, --color-interactive-primary, --color-text-muted. The token values can change for dark mode or high-contrast mode without the component needing to know anything about it.
This is also where the data dashboard UI design work gets genuinely interesting: when your chart colours are semantic tokens, you can ship a colour-blind-friendly palette mode as a user preference with very little engineering effort. ONS and DEFRA both use this kind of approach in their public data tools, and it’s something more UK product teams should be borrowing.
The other thing I’d push for is putting contrast ratio checks into your CI pipeline, not just your design review. Tools like AI-assisted code review can catch some accessibility regressions, but a dedicated linter like axe-core or pa11y will catch colour contrast failures at the component level automatically. Shift left. Find it before the release, not in a user complaint six months after.
Quick wins for teams starting from an inaccessible baseline
If you’re inheriting an existing product with a broken palette, you don’t always get to start from scratch. The quickest wins: darken your primary text colour (near-black, not pure black, ideally around #1a1a1a on white gives you headroom), lighten your backgrounds to true white or near-white, and add visible borders to all form inputs. Those three changes alone will fix a significant portion of contrast failures without touching your brand colours.
For semantic status colours, swap to filled badges with white text instead of coloured text on white backgrounds. A red badge with white text reads at roughly 5.5:1 for standard red; red text on white is usually around 3.9:1. Same brand colour, meaningfully better contrast.
Colour accessibility design is not a niche concern, and it’s definitely not a “nice to have” for UK teams building products in 2026. It’s just good design. The users who benefit most from an accessible palette are rarely the ones who make the most noise about it, which is exactly why product teams keep getting it wrong.
Frequently Asked Questions
What contrast ratio do I need to pass WCAG 2.1 AA for normal text?
Normal body text needs a contrast ratio of at least 4.5:1 between the text colour and background colour. Large text (18pt regular or 14pt bold) only requires 3:1. You can check ratios using free tools like the WebAIM Contrast Checker.
Does passing a contrast ratio check mean my design is colour blind friendly?
Not automatically. A contrast ratio check measures luminance difference, not hue distinction. Red and green can have a technically passing contrast ratio while being completely indistinguishable to someone with deuteranopia. Colour vision deficiency testing requires a separate simulation tool on top of contrast checking.
What is the most common type of colour blindness I should design for?
Deuteranopia (reduced green cone sensitivity) and protanopia (reduced red cone sensitivity) together affect roughly 8% of men in the UK. Both cause difficulty distinguishing reds, greens, and related hues. Designing for these two covers the vast majority of users with colour vision deficiency.
Are UK websites legally required to meet colour accessibility standards?
Public sector websites and apps are legally required to meet WCAG 2.1 AA under the Public Sector Bodies Accessibility Regulations 2018. Private sector products are not currently subject to the same legislation, but accessibility failures can still create liability under the Equality Act 2010 if disabled users are disadvantaged.