Colour Contrast Ratio: How to Check and Pass WCAG Contrast

A colour contrast ratio measures how different two colours are in brightness, from 1:1 (identical) to 21:1 (black on white). To pass WCAG 2.2 level AA, normal text needs at least 4.5:1 against its background, large text needs 3:1, and buttons, form borders, focus indicators and meaningful icons need 3:1. Level AAA raises text to 7:1.

Low contrast is the most common accessibility failure on the web: the WebAIM Million 2026 found low-contrast text on 83.9% of the top one million home pages. It's also one of the easiest problems to fix. It affects far more people than you might expect: anyone with low vision or colour vision deficiency, older visitors, and everyone reading a phone in bright sunshine. This guide explains exactly what WCAG contrast requires, how the ratio is calculated, what's exempt, and how to fix a palette that doesn't pass.

You can test any pair of colours with our free color contrast checker. It shows the WCAG AA and AAA result for normal text, large text and UI parts, previews the pair live and suggests the nearest shade that passes. To convert a colour between HEX, RGB and HSL first, use the colour converter.

WCAG contrast requirements at a glance

Most organisations aim for AA. It's the level UK public sector bodies must meet, the benchmark in most accessibility contracts, and achievable for almost any brand. AAA for all content is rarely required, but 7:1 for body text is a sensible target if your audience skews older.

What counts as large text?

WCAG defines large-scale text as at least 18 point, or 14 point if bold. The W3C's Understanding 1.4.3 page notes that 14pt and 18pt are roughly equivalent to 18.5px and 24px in CSS.

Two practical points. First, "bold" means genuinely bold. A 600 weight in some typefaces is close, but many thin or light display fonts at 24px still look small, so treat the threshold as a minimum rather than a goal. Second, measure the size the browser actually renders. A heading set at 1.5rem is 24px only if the root font size is 16px.

How the contrast ratio is calculated

WCAG uses relative luminance, a measure of perceived brightness, rather than simple colour differences. The steps are:

1. Convert each RGB channel from 0–255 to 0–1.
2. Linearise each channel: if the value is 0.04045 or below, divide by 12.92; otherwise apply ((value + 0.055) / 1.055) ^ 2.4.
3. Combine them: L = 0.2126 × R + 0.7152 × G + 0.0722 × B.
4. Divide the lighter colour's luminance by the darker one's, adding 0.05 to each: (L1 + 0.05) / (L2 + 0.05).

The weighting explains a lot of surprises. Green contributes most to perceived brightness and blue the least, so a bright orange can look bold yet still fail with white text.

No rounding allowed

The W3C is explicit that the computed ratio must not be rounded up: 4.499:1 does not meet 4.5:1. That makes some familiar greys right on the line:

We calculated these with the WCAG formula. One shade of grey is the difference between passing and failing, which is why eyeballing contrast doesn't work.

Brand colours often fail with white

Bright brand colours are where most businesses get caught. Some examples, calculated the same way:

The orange row is the classic case. If your brand colour is a bright orange, yellow or light green, dark text on it almost always works better than white.

Non-text contrast: buttons, inputs, icons and focus

WCAG 2.1 added success criterion 1.4.11 Non-text Contrast, and it's still at AA in 2.2. It requires a 3:1 ratio against adjacent colours for:

• Visual information needed to identify UI components and their states. If the only thing showing where a text field is is a pale grey border, that border needs 3:1 against the background. The tick in a checkbox and the position of a toggle count too.
• Focus indicators. The outline or highlight that shows keyboard users where they are needs 3:1 against neighbouring colours. WCAG 2.2 also added 2.4.11 Focus Not Obscured at AA, and 2.4.13 Focus Appearance at AAA, which sets a minimum size and contrast for the focus area.
• Parts of graphics needed to understand the content. Lines on a chart, segments of a pie chart and standalone icons such as a phone or basket icon with no text label.

There are exceptions. Inactive (disabled) components are exempt, as are controls whose appearance is set entirely by the browser and not changed by the author. Decorative graphics, and graphics whose information is also given as text, are exempt too.

A filled button doesn't always need its background to contrast 3:1 with the page, provided the text label inside it meets 4.5:1 and the button is identifiable some other way. In practice, a button that blends into the page is a usability problem even when it scrapes through, so aim for clear edges.

What's exempt from contrast rules

According to the W3C, these don't need to meet 1.4.3:

• Logos and logotypes, meaning text that is part of a logo. The exemption is for the logo itself, not for headings that happen to use brand colours.
• Inactive UI components, such as a disabled "Submit" button.
• Pure decoration, such as faint background lettering that carries no meaning.
• Text that isn't visible to anyone, and incidental text in photos with significant other visual content, like a shop sign in the background.

Disabled buttons are exempt, but a very faint disabled state can confuse people. Explain why a button is unavailable, for example "Fill in all required fields to continue".

Where contrast usually fails

Automated checks find most text failures, but some common problems are missed or misreported:

1. Placeholder text in form fields. Light grey placeholders often fail 4.5:1, and placeholders shouldn't replace labels anyway.
2. Text over images and video. The contrast changes across the image. Add a solid or semi-transparent overlay behind the text and test the lightest point.
3. Hover, focus and visited states. Each state must still meet the ratio. A link that turns pale grey on hover fails.
4. Links identified only by colour. In body text, a link that differs from surrounding text only in colour also has to satisfy 1.4.1 Use of Colour. W3C technique G183 accepts a 3:1 difference from the surrounding text plus a non-colour cue, such as an underline, on hover and focus. Keeping underlines is simpler.
5. Dark mode. If you offer a dark theme, test it separately. Pure white text on pure black can also feel harsh, so many designers soften both colours slightly while keeping a high ratio.
6. Gradients and transparency. Test the worst point of a gradient, and calculate contrast using the colour as it finally renders after opacity is applied.
7. Thin fonts. A light 300-weight font passes the formula at the same ratio as a regular weight but is much harder to read. WCAG doesn't account for weight below the large-text threshold, so use judgement.

How to fix a palette that fails

1. List every text and background pair in your design system, including buttons, alerts, links, footers and form states.
2. Test each pair in the contrast checker and note the ratio.
3. Darken the text or lighten the background in small steps. Changing lightness in HSL while keeping the hue keeps the colour recognisably "on brand".
4. Create an accessible variant of each brand colour. Many design systems keep the original for large display use and a darker shade for text and small buttons. A color palette generator that shows WCAG contrast can help you pick those shades.
5. Swap text colour on bright fills. Use near-black text on yellow, orange and light green backgrounds.
6. Document the approved pairs so new pages don't reintroduce failures.
7. Retest after changes using an automated audit, then by eye on a real phone outdoors.

Our free website audit runs Lighthouse accessibility checks, which include contrast, alongside other quick wins. For the bigger picture beyond colour, read our guide to making a website accessible with WCAG and work through the UK website accessibility checklist.

UK and US law: who has to meet WCAG contrast?

Public sector bodies in the UK must meet WCAG 2.2 level AA under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, according to GOV.UK's guidance on accessibility requirements. They must also publish and maintain an accessibility statement. The Government Digital Service monitors a sample of sites each year, and the Equality and Human Rights Commission (or the Equality Commission for Northern Ireland) handles enforcement.

Private businesses aren't covered by those regulations, but the Equality Act 2010 requires service providers to make reasonable adjustments for disabled people, and that's widely understood to include websites. WCAG 2.2 AA is the standard most likely to be used to judge whether a site is reasonably accessible. If you sell to customers in the EU, the European Accessibility Act may also apply, which our European Accessibility Act guide covers.

In the US, the Department of Justice's guidance says the Americans with Disabilities Act (ADA) requires businesses open to the public to make their websites accessible to people with disabilities. It doesn't set a technical standard, but WCAG AA is the benchmark usually used in practice, so the same contrast ratios apply.

Charities, schools and training providers often have extra obligations through funders or public contracts. Our free tools pages for charities and nonprofits and education and training collect the checks most useful to them.

What about APCA and WCAG 3?

APCA (the Accessible Perceptual Contrast Algorithm) is a newer method that accounts for font size, weight and whether text is light-on-dark or dark-on-light. It has been explored as a candidate for WCAG 3. However, WCAG 3 is still a W3C Working Draft, and the current draft says the contrast algorithm it will use is yet to be determined.

So for now, APCA is not a standard you can conform to, and no UK regulation refers to it. Meet the WCAG 2.2 ratios. If you like, use APCA as an extra design check, especially for dark mode and thin fonts, where many designers find the WCAG 2 formula less reliable.

FAQ

What is a good colour contrast ratio?

For WCAG 2.2 AA, at least 4.5:1 for normal text and 3:1 for large text and interface elements. For AAA, 7:1 for normal text and 4.5:1 for large text. For body copy, aiming for 7:1 or more gives comfortable reading for most people, including older visitors and anyone reading on a phone in sunlight.

Is 4.5:1 contrast required by law in the UK?

For public sector websites and apps, effectively yes. They must meet WCAG 2.2 AA, which includes 4.5:1 for normal text. Private businesses have no fixed legal ratio, but the Equality Act 2010 requires reasonable adjustments, and WCAG 2.2 AA is the standard usually used to judge whether a site is accessible.

What size is large text in WCAG?

At least 18 point regular or 14 point bold. In CSS that's roughly 24px for regular weight and about 18.5px for bold, assuming normal browser settings. Large text only needs 3:1 at AA, so headings can use lighter colours than body text, but anything smaller must reach 4.5:1.

Do logos need to meet contrast requirements?

No. WCAG exempts text that is part of a logo or brand name. The exemption covers only the logo itself, not other text styled in brand colours such as headings, buttons and navigation. Those still need 4.5:1 or 3:1. Logos placed on photos or coloured bars are easier to recognise if they stand out clearly anyway.

Does placeholder text need to meet contrast?

Yes. Placeholder text is text, so if it conveys information it needs 4.5:1 against the field background. Many default light grey placeholders fail. Better still, don't rely on placeholders for instructions: use a visible label above the field and put hints in text that stays on screen while people type.

Should I use APCA instead of WCAG 2 contrast?

Not as a replacement. APCA has been explored for WCAG 3, but WCAG 3 is still a draft and hasn't chosen its contrast method. Legal and contractual requirements in the UK refer to WCAG 2.2, so meet its ratios first. You can use APCA as an extra check for dark themes and thin fonts.