Website colour accessibility comes down to three numbers: 4.5:1 contrast for normal text, 3:1 for large text and interactive components, and 7:1 where you can manage AAA compliance. Every hex pairing on a live site should be checked against these ratios before launch, using a contrast checker or a programmatic test built into your development pipeline. Get this right and most of your accessibility risk disappears in one afternoon.

TL;DR:

Checking contrast ratios at every stage ensures that most accessibility issues are addressed before launch, particularly for normal and large text.

Testing should include manual, programmatic, and sample checks to cover all edge cases, especially when dealing with images, gradients, or complex visual elements.

Building a palette with defined roles and adding secondary cues like icons or patterns helps communicate information effectively to users with color vision deficiencies.

Detailed testing of all interactive states, including hover and focus, is necessary to prevent contrast failures that can hinder usability.

Prioritizing an audit that traces every color-only signal on the site, rather than solely relying on contrast ratios, leads to more genuinely accessible and usable interfaces.

What do the WCAG contrast ratios actually mean?
How do you measure and test colour contrast?
Which design rules keep colour choices accessible?
What about non-text elements like icons and focus states?
What mistakes cause most colour accessibility failures?
How does MedwayWebDesign build accessible colour into every project?
How should you design for different types of colour vision deficiency?
What accessibility guidelines matter beyond contrast ratios?
Can patterns and textures replace colour differentiation?
Does colour accessibility actually affect engagement?
How do you test with people who have visual impairments?
The gap between “technically compliant” and genuinely usable
How can MedwayWebDesign help fix your website’s colour accessibility?
Sources

What do the WCAG contrast ratios actually mean?

The Web Content Accessibility Guidelines set three thresholds, and each applies to a different type of content. Normal body text needs 4.5:1. Large text, defined as 18pt (24px) regular or 14pt (18.5px) bold, needs 3:1. User interface components and graphical objects that convey required information also need 3:1.

The number is not measuring how “different” two colours look to the eye. It’s measuring relative luminance, the brightness value calculated from linearised sRGB values, not hue. This is why designers repeatedly get caught out: a vivid orange on a mid blue can look like a strong contrast, but if both colours sit at similar brightness levels, the ratio fails. WebAIM’s guidance recommends converting your palette to greyscale as a sanity check. If two swatches blur together in grey, they’ll fail in colour too.

A few practical exceptions exist:

Logos and brand marks are exempt from contrast requirements.
Incidental text, such as text inside a photograph with no functional purpose, doesn’t need to meet the ratio.
Disabled form controls are generally exempt, since they’re not currently operable.

Aim for AAA (7:1) on your primary body copy wherever your brand palette allows it. WAI’s own guidance notes that the higher ratio compensates for the reduced contrast sensitivity that comes with ageing eyes or low vision, a growing share of any web audience.

How do you measure and test colour contrast?

Colour accessibility tests fall into three categories, and a solid workflow uses all three at different stages.

Manual tools are your first line of defence. Chrome and Firefox DevTools both include a colour picker that reports computed hex values and a contrast ratio directly against the background. Online contrast checkers let you paste two hex codes and get an instant pass/fail against AA and AAA.

Programmatic checks catch what manual spot checks miss at scale. Tools like axe and ANDI scan a full page and flag every failing combination automatically, which matters once a site has hundreds of components. Section508 exactly this combination: automated scanning backed by manual sampling for anything a script can’t parse, like gradients.

A workable testing sequence looks like this:

Capture the exact hex values in use, not the ones in your design file.
Run the pairing through a contrast checker against AA and AAA thresholds.
Test every interactive state: default, hover, focus, and disabled.
Check images and gradients at their worst-contrast point, not their average.
Re-test after any brand refresh or theme change, since a single token update can break dozens of components at once.

Programmatic checks are fast and consistent but can’t judge subjective cases like text sitting over a photograph. Sample-based checks are slower but catch the edge cases automated tools miss. Use programmatic scanning as your baseline and manual sampling for anything visually complex.

Pro Tip: When checking a gradient background, find the lightest point where your text sits and test contrast there. If the palest pixel fails, treat the whole element as failing, because that’s where a real user’s eye will struggle.

Which design rules keep colour choices accessible?

Luminance, not hue, decides whether a pairing works. Test greyscale versions of your brand colours before you commit to a palette, because two colours that look worlds apart can share almost identical brightness values.

Build your palette with defined roles rather than picking swatches ad hoc:

A core text colour (or two, for light and dark backgrounds) that clears 4.5:1 against every background it appears on.
Background colours chosen alongside the text colours, not after.
Accent colours reserved for elements that meet the 3:1 threshold when used on buttons or icons.
Utility colours for success, warning, and error states, each tested independently rather than assumed to inherit the accent’s contrast.

Never let colour alone carry meaning. A red error message with no icon, label, or border change is invisible to a user who can’t distinguish red from green. Pair colour cues with text, iconography, or an underline on links, so the information survives even when the colour doesn’t land.

Where a constrained brand palette makes 4.5:1 difficult, increasing font weight or size can shift text into the “large text” category, dropping the requirement to 3:1. Medway Web Design’s guide to choosing brand colours covers how to build this flexibility into a palette from the start rather than retrofitting it later.

What about non-text elements like icons and focus states?

WCAG 1.4.11 covers anything that isn’t text but still carries meaning: buttons, form field borders, toggle switches, icons, and focus indicators. Any of these needs 3:1 contrast against its adjacent colours when a user needs it to identify or operate the control.

Test every state, not just the default. A button that passes at rest often fails on hover or focus if the state change relies on a subtle colour shift rather than a genuine brightness difference.

Check default, hover, focus, and disabled states as separate contrast tests.
Verify focus indicators meet 3:1 against both the control and the surrounding background.
Use borders, drop shadows, or visible outlines to lift contrast on brand-constrained elements without changing the core colour.

Pro Tip: If your brand’s primary colour can’t hit 3:1 against white, add a 1px darker border around the control rather than repainting it. It’s often the fastest fix that doesn’t touch brand guidelines.

What mistakes cause most colour accessibility failures?

Most failures trace back to the same handful of habits, repeated across otherwise well-built sites.

Judging contrast by eye instead of measuring it. A colour that “looks fine” on a calibrated design monitor can fail badly on a budget laptop screen.
Placing text over background images without a solid layer behind it. Even a strong-contrast colour fails the moment it sits over a busy photograph.
Skipping interactive states during testing. A form that passes at rest can fail entirely once a user focuses a field or hovers a button.
Removing link underlines for a cleaner look. Without an underline, colour becomes the only cue, which fails users who can’t distinguish it from surrounding text.

Fast fixes: swap to a darker or lighter palette variant, add a solid background block behind text-on-image, reinstate underlines on inline links, and bump font weight where size is fixed. Run a pre-release checklist covering colours, every component state, and any image with overlaid text before a site goes live. Common UI mistakes like these are covered in more depth in Medway’s rundown of frequent design errors.

How does MedwayWebDesign build accessible colour into every project?

MedwayWebDesign treats colour accessibility as a build stage, not an afterthought bolted on before launch. Palette creation starts with contrast testing built in from the first mood board, not applied retrospectively once a client has fallen in love with a shade.

The practical workflow runs in stages:

Draft palette tested against AA thresholds before any screen design begins.
Component library checked state by state, including focus and disabled variants.
Pre-launch QA pass across every page template, checking text-on-image and gradient edge cases.

Author Ian Rickard has applied this process across MedwayWebDesign client projects where a signature brand colour initially failed 4.5:1 against white. Rather than abandon the colour, the fix was darkening it by a few percentage points in luminance while holding hue constant, a change invisible to most users but enough to clear AA. Case examples of this kind of adjustment sit alongside broader notes on contrast and readability in MedwayWebDesign’s project write-ups.

How should you design for different types of colour vision deficiency?

Colour vision deficiency isn’t one condition. NHS guidance outlines several distinct forms, and each affects perception differently enough that designing for “colour blindness” as a single category misses the point.

Protanopia and deuteranopia, the two most common forms, both affect red-green discrimination, though for different underlying reasons. Someone with protanopia struggles to perceive red tones at all, while deuteranopia shifts green perception, and together they make red/green pairings, the single most common colour-coding choice on the web, unreadable to a meaningful share of users. Tritanopia is rarer and affects blue-yellow discrimination instead, which catches out designers who assume blue is always a “safe” alternative to red.

The practical implication is the same across all three: never encode a binary state, like “error” versus “success”, purely through a red/green or blue/yellow swap. Test your palette against simulated colour vision deficiencies using a tool such as Testuno’s colour sensitivity test, which lets you preview how an interface renders under different deficiency types before it ships.

Where colour differences must communicate something, add a second channel: an icon, a text label, a pattern, or a position change. A form field that turns red on error should also show an inline message and an icon, so the meaning survives regardless of how the user perceives red. This layered approach costs almost nothing in design time and removes an entire class of accessibility failure at once.

What accessibility guidelines matter beyond contrast ratios?

Contrast ratios solve legibility. They don’t solve the separate problem of colour-only meaning, which is where WAI’s guidance on use of colour becomes essential reading alongside the contrast success criteria.

The guidance is specific: information conveyed by colour should also be available through shape, text, or position, because a colour-vision deficiency doesn’t just make colours harder to read, it can make them indistinguishable from one another entirely. A stock chart that shows gains in green and losses in red, with no numeric labels, communicates nothing to a user who can’t separate the two.

Certain colour pairings cause disproportionate trouble and are worth avoiding as a default rule, not just testing reactively:

Red and green together, especially without a third distinguishing cue, fail for the majority of colour-vision-deficient users.
Green and brown, or green and orange, cause similar confusion for red-green deficiencies.
Blue and purple can blur for some tritanopia cases, particularly at low saturation.

None of this means avoiding these colours entirely. It means never letting them be the only signal. A status dashboard can still use a green-to-red gradient, provided every data point also carries a label, an icon, or a numeric value that stands on its own. Charts should use varied line styles or direct labelling rather than colour-only legends. Form validation should pair colour with an icon and a written message every time, not occasionally.

This is where a genuinely accessible design system pays for itself: build the redundancy in once, at the component level, and every future page inherits it automatically rather than depending on each designer remembering the rule.

Can patterns and textures replace colour differentiation?

Yes, and they’re often the simplest fix available when a palette is already fixed and can’t be repainted for accessibility reasons.

Pattern fills work particularly well in data visualisation. A bar chart can use diagonal hatching for one series and solid fill for another, so the distinction survives even if both bars render as similar greys to a colour-deficient viewer. Line charts benefit from varying dash styles, dotted versus solid versus dashed, rather than relying purely on line colour.

Texture and shape do similar work in interface design. A toggle switch that changes both colour and position (on the left when off, on the right when on) communicates state through two independent channels. A selected tab that gains a solid underline as well as a colour shift remains legible even if the colour change alone wouldn’t register.

Icons deserve particular attention here because they’re the cheapest fix with the widest reach. Pairing a checkmark icon with “success” and a cross icon with “error” means the message survives regardless of how either colour renders for a given viewer. This costs a designer perhaps ten minutes per component and removes reliance on colour perception entirely for that interaction.

The general principle: any place where colour currently does the entire job of conveying a distinction is a place worth adding a second cue. It rarely disrupts the visual design meaningfully, and it usually makes the interface clearer for every user, not just those with a colour vision deficiency. Clean, high-contrast type paired with these secondary cues also tends to read faster for all users under poor lighting conditions or on lower-quality screens, which is a usability win that has nothing to do with disability at all.

Does colour accessibility actually affect engagement?

Poor contrast doesn’t just fail an audit. It causes measurable friction in how people actually use a site, particularly on mobile screens viewed outdoors or under glare, where marginal contrast becomes unreadable contrast almost instantly.

Low-contrast body text forces users to work harder to parse a page, and that extra cognitive load shows up as shorter session times and higher bounce rates on content-heavy pages. Buttons that fail the 3:1 non-text threshold against their background become harder to locate at a glance, which slows down conversion flows and checkout processes specifically, the pages where speed and clarity matter most to revenue.

There’s also a demographic dimension worth taking seriously rather than treating as a niche concern. Age-related contrast sensitivity decline is common, and a meaningful share of any general audience, not just users who identify as having a visual impairment, will benefit from AAA-level contrast on primary reading text. Designing for the accessibility minimum often means designing for a more comfortable reading experience across the entire user base, including people with no diagnosed condition who simply find low-contrast interfaces tiring to use for extended periods.

The reverse holds too. Sites that get contrast right tend to see fewer support queries related to “I can’t find the button” or “I can’t read this”, because the interface does the explaining visually rather than requiring a user to hunt or guess. That’s a quieter benefit than a conversion uplift, but it compounds over the life of a site, particularly for e-commerce and service businesses where every unnecessary support ticket has a real cost attached.

How do you test with people who have visual impairments?

Automated tools and contrast checkers catch a large share of accessibility issues, but they can’t replace direct observation of someone actually using your interface. Combining both remains the most reliable approach.

Simulation tools are the accessible starting point for most teams. Browser extensions and dedicated testing platforms can render a page as it would appear under protanopia, deuteranopia, or tritanopia, letting a designer catch obvious failures before any real user is involved. Screen reader testing with VoiceOver or NVDA, while primarily aimed at blind and low-vision users rather than colour-deficient ones, also surfaces cases where visual-only cues have no equivalent announced to assistive technology.

Recruiting participants with lived experience of low vision or colour vision deficiency for a moderated usability session remains the gold standard, even for a short, informal round of five or six people. These sessions tend to surface issues that no automated scan catches: a colour-coded status system that makes sense to the design team but confuses someone with deuteranopia within seconds, or a focus indicator that’s technically compliant but still hard to track visually while tabbing through a long form.

Where formal user testing isn’t feasible for a smaller project, a hybrid approach works well: run automated and simulation testing internally, then commission a short accessibility statement review from a specialist to sense check the findings before launch, a step Live Caption AI’s resources on accessibility statements cover in more detail for teams new to the process.

The gap between “technically compliant” and genuinely usable

Most colour accessibility advice stops at the contrast checker, and that’s a mistake. Passing 4.5:1 tells you text is readable in isolation; it says nothing about whether your error states, your charts, or your status indicators still make sense to someone who can’t distinguish red from green. I’d argue the industry has over-indexed on the numeric thresholds precisely because they’re easy to automate and easy to badge as “done”, while the harder work, auditing every colour-only signal across a live product, gets skipped because no single tool flags it cleanly.

The conventional advice also underestimates how often accessibility and legibility for everyone else point in the same direction. AAA contrast doesn’t just help users with low vision; it reduces reading fatigue for anyone using a phone outdoors. Teams that treat 7:1 as a nice-to-have rather than a default are leaving a genuine usability gain on the table for a fairly small design cost.

If you take one thing from this guide, prioritise the audit over the checklist. Run your palette through a contrast tool, yes, but then physically trace every place colour alone carries meaning on your site and ask whether it would still make sense in greyscale.

— Ian Rickard

How can MedwayWebDesign help fix your website’s colour accessibility?

MedwayWebDesign builds accessible contrast into a project from the first palette draft rather than retrofitting it once a client’s site is already live, which is where most agencies start and where most of the expensive rework happens. That means fewer surprises during QA and a lower chance of an accessibility complaint landing after launch.

Services relevant to what this guide covers include accessible colour audits on existing sites, UI component library builds that pass AA (and AAA where the brand allows), and pre-launch accessibility QA covering every interactive state, not just the default view. If your current site relies on colour-only status indicators or has never had its palette tested against WCAG thresholds, that’s usually the fastest place to start.

Get in touch to request a colour accessibility review, or read more about how MedwayWebDesign approaches custom web design for small businesses that want the audit and the fix handled together.

Fix website color accessibility in an afternoon using tool checks

Table of Contents