Colour Contrast – The Easiest Accessibility Win Hiding In Plain Sight

I’ve lost count of the number of design reviews I’ve sat in where someone drags a lovely light-grey paragraph onto a white background and everyone nods along because it ‘looks clean’. It does look clean, but it also might be unreadable or at least very hard to read for a chunk of the people trying to use it.

Colour contrast is one of those accessibility issues that sounds small. It’s ‘just’ a colour choice, right? But it’s consistently the single most common accessibility failure on the web, year after year. So I wanted to write down what I know about it, what WCAG actually asks for, why it matters more than most teams assume, and how to get it right without turning your interface into a black-and-white legal document.

The Stat That Should Worry Every Designer, Developer & Website Owner

Every year, WebAIM scans the homepages of the top one million websites and reports back on what’s broken. Low contrast text has topped that list for seven years running, and it’s not getting better. In the most recent report, low-contrast text below the WCAG AA threshold was found on 83.9% of home pages, up from 79.1% the year before (which is disheartening). The average page had 34 separate instances of it.

Read that again. On the vast majority of sites on the internet, someone somewhere put text on the screen that a meaningful number of visitors literally cannot read comfortably. It’s not some rare edge case, it’s closer to being the default state of the web.

Yet it’s an easy problem to fix, at least when compared to a lot of other accessibility issues found on websites. You don’t need to rebuild your navigation or rewrite the ARIA markup for this one, you need to pick a slightly darker grey.

Who This Actually Impacts

Colour and contrast issues aren’t just about a small niche of screen reader users (not that we should be discounting that group either).

They affect:

• People with low vision – Which becomes more common as we age. Most of us will experience some decline in contrast sensitivity over our lifetimes.
• People with colour vision deficiency – Roughly 8% of men and 0.5% of women worldwide have some form of colour blindness, which works out to around 300 million people globally. That’s more than the entire population of the United States!
• People with specific conditions that reduce contrast sensitivity, separately from sharpness or colour vision – Cataracts, glaucoma, age-related macular degeneration, diabetic retinopathy, and optic neuritis can all leave someone with reasonably good visual acuity on an eye chart while still struggling badly to tell a pale object from its background. Migraine with visual aura and photophobia can produce similar effects, at least temporarily.
• People who are autistic, or who have ADHD, migraine, or related visual sensory differences – This cuts the other way to most of the list above. Rather than needing more contrast, a documented portion of this group finds high contrast physically uncomfortable. There is more on the research behind this below.
• People who experience visual stress from high-contrast patterns – Sometimes discussed under the term Irlen syndrome (also called Meares-Irlen syndrome or scotopic sensitivity syndrome). It’s worth noting this one is more contested than the others, as it isn’t universally recognised as a distinct diagnosis in mainstream ophthalmology, but people who describe glare, distortion, or discomfort from stark black-on-white text are a real and fairly common part of the audience, whatever label you use for it. In practice this points the same direction as the rest of this list: avoid pure black on pure white for large blocks of text, and offer ways to soften that where you can (an off-white background, a slightly reduced max contrast, adjustable themes).
• Anyone using a device outdoors, in bright sunlight, on a low-quality screen, or with a cracked or scratched display – you’ve no doubt experienced this on a bright day when browsing on your phone.
• Anyone who’s just tired, distracted, or reading on a small phone screen on the train.

That last point is worth sitting with. Accessibility is often framed as ‘designing for disabled users’ and that’s true and important, but good contrast makes things easier for literally everyone. Nobody has ever complained that text was too easy to read.

But it’s also not one uniform need. Most of this list needs more contrast to read comfortably. The autism/migraine/visual-stress group above needs it dialled back rather than pushed to the maximum. WCAG’s contrast criteria set a floor for the first group, but say nothing about a ceiling for the second. So it is worth keeping in mind rather than assuming ‘more contrast’ is always the safer choice.

What WCAG Actually Requires

WCAG’s AA contrast rules live mainly under Success Criterion 1.4.3 (Contrast Minimum) and 1.4.11 (Non-text Contrast), plus 1.4.6 for the stricter AAA level.

Here’s the short version:

Text contrast (WCAG 2.x, Level AA – the level most legal and organisational standards target):

• Normal-sized text needs a contrast ratio of at least 4.5:1 against its background.
• Large text (roughly 18pt/24px regular, or 14pt/18.5px bold, and up) needs at least 3:1.

Non-text contrast (Level AA):

• UI components (buttons, form field borders, toggle states, icons that convey meaning) and graphical objects need at least 3:1 against adjacent colours.

Enhanced contrast (Level AAA, stricter, not usually required but good practice for critical content):

• Normal text: 7:1
• Large text: 4.5:1

Separately from contrast ratios, there’s Success Criterion 1.4.1 (Use of Color), which is easy to forget. Don’t use colour as the only way to convey information. If your form marks errors purely by turning the border red, or your chart distinguishes categories purely by hue, someone with colour vision deficiency (or a black-and-white printout, or a poor screen) loses that information entirely.

Practical Advice That Actually Helps

A few things I keep coming back to:

1. Check contrast early, not at the end – Contrast is far easier to fix in a design file than after a component that is in production and been copy-pasted into forty places. Build your colour palette against the ratios above from day one (in your brand guidelines for web ideally).

2. Use a proper contrast checker, not your eyes – Our eyes are bad at judging this consistently. Screen calibration, lighting, and fatigue all skew perception. WebAIM’s Contrast Checker is free and simple. Design tools like Figma have plugins (Stark is a popular one) that flag failures inline. Chrome DevTools also has a contrast ratio readout built into its colour picker.

3. Don’t just check body text – Placeholder text, disabled states, form field borders, focus indicators, icon-only buttons, and chart labels are the things people forget. They’re covered by WCAG too, and they’re the ones that fail most often in real audits.

4. Pair colour with a second cue – For errors, use an icon and text, not just a red border. For charts, use patterns or labels alongside colour. For links in body text, keep the underline, as colour alone isn’t enough to signal that ‘this is clickable’.

5. Test with actual colour blindness simulation – Tools like Coblis, RGBlind, the Chrome DevTools vision deficiency emulator, or Sim Daltonism on Mac, let you see your interface the way a meaningful percentage of your users actually will. It’s a genuinely humbling five minutes.

6. Dark mode isn’t automatically accessible – Flipping your palette for dark mode can quietly break contrast ratios you’d already fixed for light mode. Check both themes independently, as they’re not the same problem solved twice.

7. Remember large text gets a break, but don’t lean on it – The 3:1 threshold for large text exists because bigger glyphs are inherently easier to resolve, not because large text matters less. Don’t use “well, it’s a big heading” as an excuse for a washed-out brand colour.

Tools Worth Having Open While You Work

Automated tools will catch most contrast problems for you, but it’s worth knowing what each one is actually good at:

• WebAIM Contrast Checker – the simplest option. Paste in a foreground and background hex value and it tells you the ratio and whether it passes AA/AAA for normal and large text. Good for spot-checking a single pairing.
• Chrome DevTools colour picker – click any colour swatch in the Styles panel and it shows the contrast ratio live, with a small line indicating where AA and AAA sit as you adjust the colour. Useful because it’s already in your normal workflow.
• Stark/Able/Contrast (Figma and Sketch plugins) – these let you check contrast directly in the design file, before anything gets built, and some will flag failing pairs across a whole page automatically.
• axe DevTools/WAVE – browser extensions that scan a live page and flag a wide range of accessibility issues, contrast included. Good for auditing pages that already exist.
• Chrome DevTools – ‘Emulate vision deficiencies’ (under Rendering settings) and Sim Daltonism (macOS). These simulate different types of colour blindness so you can see your interface the way a colour-blind user actually would, rather than guessing.

A Quick Manual Check You Can Do In Five Minutes

Automated tools are a starting point, not the finish line. They can tell you a ratio is mathematically fine and still miss a real problem (text sitting over a busy photo, a gradient that dips below threshold in one spot, a focus outline that disappears on hover). A quick manual check can catch what tools can miss:

1. Zoom out and squint, or step back from the screen. If a piece of text disappears or blurs into its background, that’s a real signal, not just a vibe, so go check the actual ratio.
2. View the page in greyscale (a browser extension or your OS’s greyscale display filter works). If two adjacent elements (a button and its background, an active tab and an inactive one) become indistinguishable, you’re relying on hue rather than contrast.
3. Turn your monitor brightness down, or check the page outdoors on a phone. This mimics the low-vision and glare conditions a lot of real users are actually in.
4. Tab through the page with your keyboard only. While you’re checking contrast, check whether the focus indicator is visible against every background it lands on. It needs to meet the same 3:1 non-text contrast requirement, and it’s one of the most commonly broken parts of a site.
5. Print the page, or view it in black and white. Sounds old-fashioned, but it’s a fast way to catch anything relying purely on colour to convey meaning, like a chart legend, a status label, a required-field marker.

None of this requires special equipment or specialist training. It’s mostly a matter of building the habit of actually looking, rather than trusting that a design token named ‘text-secondary’ is automatically fine.

Contrast Is One Piece Of A Much Bigger Picture

I want to be careful not to leave the impression that if you fix contrast, you’ve ‘done’ accessibility, “completed it mate”. You haven’t. You’ve fixed the most commonly broken thing, which is genuinely valuable, but it’s a small piece of what WCAG covers.

WCAG 2.2 contains 87 success criteria in total, organised under four principles – Perceivable, Operable, Understandable, and Robust (POUR). Colour and contrast sit entirely within the first of those. The other three cover things like:

• Whether the site can be used without a mouse at all – keyboard navigation, visible focus order, no keyboard traps.
• Whether screen reader users get meaningful information – semantic HTML, proper headings, alt text, form labels, ARIA used correctly rather than sprinkled on for luck.
• Whether people with cognitive or learning disabilities can follow what’s happening – plain language, consistent navigation, clear error messages, enough time to complete tasks.
• Whether content still works with assistive technology as browsers and screen readers evolve – valid, well-structured code.

A site can have perfect contrast ratios everywhere and still be completely unusable for someone navigating by keyboard, or someone whose screen reader hits a button with no accessible name, or someone who can’t parse a wall of jargon in an error message.

Contrast is popular to talk about partly because it’s visual and easy to demonstrate, and partly because automated tools catch it reliably, but the accessibility issues automated tools can’t catch (confusing navigation, unclear instructions, missing keyboard support, ARIA that lies about what’s on screen) tend to be at least as disruptive, if not more so, and they need actual manual testing with real assistive technology to find.

So treat this post as a solid, high-leverage starting point, not a checklist you can tick off and move on from.

What To Take Away

Contrast failures persist not because they’re hard to understand, but because they’re easy to deprioritise. A pale grey looks more ‘premium’ in a mockup, nobody in the room has a vision impairment, and the ratio math feels like someone else’s job. But the numbers make it clear this isn’t a fringe concern. It’s the most common thing wrong with websites today, and it’s one of the few accessibility issues you can fix with a hex code change rather than deeper development.

If you only take two things from this:

First – before you push a design into production, run your actual colour pairs (text, icons, borders, statesA) through a contrast checker, then do the five-minute manual pass above.

Second – don’t let fixing contrast feel like the finish line. It’s the easiest win on a much longer list, and the rest of that list (keyboard access, screen reader support, plain language) is where a lot of the harder, more important work still lives.

Is It Time For A Website Redesign?

If you’d like to learn more about our website redesign approach and if it could be a good fit for your business, drop us an email or give us a call.