Bridgewell/Media
Accessibility guide

Hard-to-read text (low contrast): what it is, who it shuts out, and how to fix it

What it is

Low contrast happens when the colour of your text is too close to the colour of its background. Think light grey body copy on a white page, pale blue links that almost disappear, or a "Book now" button where the label is barely distinguishable from the button itself.

The Web Content Accessibility Guidelines set a minimum in WCAG success criterion 1.4.3 (Contrast — Minimum). For standard body text, the foreground-to-background contrast ratio must be at least 4.5:1. For large text — defined as 18pt (roughly 24px) or 14pt bold (roughly 18.67px bold) — the minimum drops to 3:1.

A contrast ratio is simply a number: 1:1 is identical colours (invisible text); 21:1 is black on white (maximum). Most designers don't calculate these by eye; they use a tool. But many sites still ship with ratios of 2:1 or 3:1 on body text, often because a brand colour that looks fine on a designer's calibrated monitor fails badly on a budget laptop screen in a bright room.

The failure tends to creep in at a few predictable points: placeholder text in form fields, disabled-state buttons, footer text, small print, and brand colours applied directly to text without checking the numbers.

---

Who it shuts out

The obvious answer is people with low vision or certain types of colour blindness — and yes, an estimated 1 in 12 men in the UK have some form of colour vision deficiency. But the real business answer is broader than that.

Older customers. Contrast sensitivity declines with age. By the time someone is in their 60s, they need significantly more contrast to read comfortably than they did in their 30s. If your customers skew older — and for most UK small businesses, a good share do — low contrast is actively losing you sales.

Everyone on a phone in daylight. Screen glare on a smartphone in sunshine reduces effective contrast. Text that passes the 4.5:1 test barely scrapes by; text that fails it becomes genuinely unreadable outdoors.

People with migraines or reading difficulties. Low contrast forces the eye to work harder. Users who already find sustained reading difficult — whether due to dyslexia, migraine sensitivity, or fatigue — will leave rather than strain.

Anyone on a cheap or older monitor. Not everyone has a high-end display. The customer browsing your site on a five-year-old laptop in a bright kitchen is not an edge case.

Losing these users doesn't show up as an error in your analytics. It shows up as a slightly higher bounce rate and slightly lower conversions — quietly, persistently, every day.

---

How to tell if your site has it

The fastest self-check: look at your site on your phone in a well-lit room, then step outside. If you're squinting or scrolling past text rather than reading it, there's a contrast problem.

For a more systematic check:

  • Open Chrome DevTools (right-click → Inspect), click any text element, then click the colour swatch next to the color property in the Styles panel. Chrome shows the contrast ratio inline and flags it as failing or passing AA.
  • Run Google Lighthouse. In Chrome DevTools → Lighthouse → Accessibility. It reports low-contrast text elements directly, with the calculated ratio and the required minimum.
  • Check your brand colours. If your primary brand colour is a mid-tone (anything that looks like a pastel, or a colour that could go either on a dark or light background), it almost certainly fails on white.

Watch especially for: grey placeholder text in input fields, footer text in a light brand colour, price text or legal small print styled lighter than the main copy, and call-to-action buttons where the label colour was chosen for aesthetics rather than readability.

---

How we fix it

The fix is always a colour change in the CSS — nothing else. There are no shortcuts.

We don't use accessibility overlays or widgets. These tools layer JavaScript on top of your page and attempt to recolour text dynamically. In practice, they conflict with screen readers, fail unpredictably across browsers, and don't actually change your underlying markup. Several businesses have been sued under UK and US accessibility law while running an overlay, because courts look at whether the underlying site is accessible — not whether a patch is attached. We refuse to recommend them.

The real fix looks like this:

```css /* Before — fails WCAG 1.4.3 at approximately 3.1:1 on white */ body { color: #999999; }

/* After — passes at 7:1 on white */ body { color: #595959; } ```

For a brand colour that fails when used as text, we either darken it (for text on light backgrounds) or lighten it (for text on dark backgrounds) until it meets 4.5:1, then test it against your actual background colours — not just white.

What automated tools catch, and what they don't

Automated scanners like Axe and Lighthouse reliably catch static text where the colour values are declared directly in your CSS and the background is a flat colour. That covers most of the low-hanging fruit.

What they miss:

  • Text in images. A banner with text baked into a photo can fail badly; no scanner reads it.
  • Gradient backgrounds. If the background shifts from dark to light, contrast varies across the text — a scanner typically checks one point.
  • Dynamic states. Text that only appears on hover, focus, or in an error message is often missed unless the scanner is set up to trigger those states deliberately.
  • User-submitted content. If your CMS lets staff or customers post content, the scanner can't check what isn't on the page yet.

This is why automated tools, used alone, reliably catch only around 30–40% of WCAG issues. The rest requires a human looking at the site across its actual states and content.

Our process

We run an automated audit first to surface the obvious failures fast. Then a human reviewer goes through the site in real states — forms filled in, errors triggered, hover and focus states active — checking what the scanner couldn't. Every finding is reported back to you in plain English, not a spreadsheet of WCAG references.

We fix contrast issues by updating your CSS (or your design tokens, if you use a design system), so the fix is permanent, not fragile.

---

If you want to know exactly where your site stands, our free Accessibility Snapshot gives you an automated WCAG scan plus a quick human review, delivered as a plain-English report — no jargon, no upsell pressure. It's a useful starting point whether you go on to work with us or not. You can request one using the form on this page.

Free · No catch

See what your site is shutting out — for free.

Drop in your website address and we'll run an automated WCAG 2.2 check plus a quick human review. A plain-English report lands in your inbox — what's failing, why it matters, and what it'd take to fix. No card, no sales pressure.

Get a free Accessibility Snapshot Or just email us Typical reply time: same working day.