What Is Color Contrast? Enhance Visual Accessibility

Every piece of text sits on some background, and the luminance gap between the two is what color contrast describes. It gets reported as a contrast ratio from 1:1 to 21:1.

WCAG 2.2 sets the Level AA minimum at 4.5:1 for normal text and 3:1 for large text, icons and form controls. Low vision and color vision deficiency are the obvious cases, and the contrast sensitivity people lose with age puts plenty of other readers in the same spot. Below those minimums, text stops being readable for them.

The 4.5:1 figure is derived rather than chosen. W3C takes the 3:1 baseline for normal vision and multiplies it by the roughly 1.5 contrast sensitivity loss that Arditi and Faye (2004) tied to 20/40 acuity.

What is color contrast?

Take any foreground color and the background behind it. How far apart their luminance sits is the color contrast between them.

The number that expresses it is a contrast ratio. It’s unitless and runs from 1:1 for two identical colors up to 21:1 for black on white.

Luminance means perceived lightness, not hue. W3C builds the calculation so that hue is not a key factor, which is why pale yellow on white fails even though the two colors look different.

Any pair that has to be told apart has a contrast value. Body text against its background has one. So does a button label against the button fill, an icon against the page behind it, and a form field border against the area around the field.

The same formula covers every one of them. Only the required minimum changes by element type.

Who low color contrast affects, and how often sites fail

Contrast shows up in nearly every web accessibility audit, mostly because it’s easy to measure and easy to get wrong.

People with low vision take the hardest hit. Reduced contrast sensitivity makes faint text and borders disappear first for them. Color vision deficiency matters too, though luminance contrast helps there because it doesn’t depend on hue. Contrast sensitivity also declines as vision ages, and bright light or a weak small-screen display cuts the effective contrast for everyone.

W3C documents one exception. Red and other long-wavelength colors on black are harder to read for people with protanopia, so a passing ratio can overstate legibility there.

The WebAIM Million 2026 crawled 1,000,000 home pages in February 2026 and found low contrast text on 83.9% of them. The 2025 edition measured 79.1%. Pages averaged 34 distinct low contrast instances, up 15% in a year.

Common Crawl’s February 2026 audit of 240 domains comes at the problem from the other side. It pulls color pairings out of archived crawl data and finds roughly four in ten fail the 4.5:1 threshold for normal text.

The two methods count different things (pages with at least one failure versus individual pairings), but they agree on direction. Common Crawl adds that a lot of the failing text turns out to be navigation links and footers, along with form labels. It also flags that styles held in external stylesheets are invisible to its method, so the exact share is approximate.

Brand palettes fail too. CU Boulder’s accessibility guidance lists CU Gold on white at 1.9:1, which rules it out for text of any size and for meaningful images.

How the contrast ratio is calculated

The formula is (L1 + 0.05) / (L2 + 0.05). L1 is the relative luminance of the lighter color, L2 the relative luminance of the darker one.

Results run from 1 to 21. W3C applies the threshold to the unrounded value, so 4.499:1 does not meet 4.5:1.

What relative luminance measures

Relative luminance puts brightness on a scale from 0 (darkest black) to 1 (lightest white), computed in the sRGB color space.

Each 8-bit channel gets divided by 255, converted to linear light, then weighted by 0.2126 for red, 0.7152 for green and 0.0722 for blue.

Green carries most of the weight, which is why pure green reads far lighter than pure blue.

According to W3C’s notes on the formula, the 0.05 offset stands for typical viewing flare. In May 2021 W3C also changed the linearization threshold in the definition from 0.03928 to 0.04045, a change with no practical effect on results (Understanding docs, updated September 2026).

A worked example with two hex colors

Convert each hex code to RGB channel values first (a hex-to-RGB converter handles it), so #777777 becomes 119, 119, 119.

All three channels are equal in a neutral gray, so the luminance equals the linearized channel value. For #777777 that is 0.1845, and against white (luminance 1.0) the ratio is 1.05 / 0.2345, or 4.48:1.

One hex step separates the failing gray from the passing one. #767676 is the lightest neutral gray that clears 4.5:1 on white, so it’s a handy value to remember. That gap is the reason the no-rounding rule exists.

What contrast ratios does WCAG 2.2 require?

At Level AA, WCAG 2.2 asks for 4.5:1 on normal text and 3:1 on large text. Level AAA raises those to 7:1 and 4.5:1. UI components and graphical objects need 3:1 at AA.

The criteria sit in the W3C Recommendation dated 12 December 2024, written by the Accessibility Guidelines Working Group. The Understanding documents, hosted by the Web Accessibility Initiative, explain each one.

Placeholder text counts as text under 1.4.3, and so does anything revealed on hover or on focus.

What counts as large text?

The cutoff is 18pt at regular weight, or 14pt if the text is bold.

In CSS terms, 18pt works out to 24px. Bold 14pt comes to about 18.5px at W3C’s conversion of 1pt = 1.333px.

CSS sizes come in pixels, so a px to pt converter saves a calculation when a design file lists points.

W3C adds a caution. Fonts with extraordinarily thin strokes are harder to read at lower contrast, so the 3:1 allowance suits sturdy typefaces best.

Where do 4.5:1 and 7:1 come from?

ISO 9241-3 and ANSI/HFES 100-1988 set 3:1 as the minimum for standard text and normal vision.

WCAG scales that up for vision loss. Arditi and Faye (2004), cited in W3C’s rationale, tie 20/40 acuity to a contrast sensitivity loss of roughly 1.5, so 3 x 1.5 gives 4.5:1. The same logic puts 20/80 at about 7:1.

Users with worse loss than 20/80 usually rely on assistive technology that already adds contrast enhancement and magnification, per W3C.

Contrast for icons, form fields and focus indicators

SC 1.4.11 extends the 3:1 floor beyond text.

Visual information needed to identify user interface components and their states must reach 3:1 against adjacent colors, and so must the parts of a graphic needed to understand it.

For form fields, that means the border or fill that shows where the field is. Checkboxes and radio buttons need the box to pass, along with the check and the selected fill. Icons without text have to pass as a whole. Author-styled focus indicators must pass too, while default browser focus styles are exempt.

W3C’s failing examples include a light gray checkbox border on white and a pale gray focus outline, both under 3:1.

Hover effects are not held to 3:1, because the pointer position already shows hover. The control itself must not lose contrast, though. WCAG 2.2 also adds Focus Appearance (2.4.13, AAA) for stricter focus indicator rules.

Which level should a site target?

Target AA everywhere, then push body text toward 7:1 where the palette allows.

AA at 4.5:1 covers users with moderately low vision, about 20/40, and it’s the floor for every text and component pair. AAA at 7:1 compensates for roughly 20/80 vision in users who don’t use assistive technology. It’s a stretch for secondary text on tinted backgrounds, so apply it to body copy first.

When do the contrast rules not apply, and where do passing ratios still fail?

The rules skip a short, closed list of cases.

What the exemptions cover

SC 1.4.3 lists the text exemptions, and SC 1.4.11 adds one for graphics.

Text on an inactive control is exempt, such as a submit button waiting for required fields. Pure decoration is exempt too, meaning text whose words could be swapped without changing the meaning, like random words faded into a cover background. Invisible text is out, as is text inside pictures that contain significant other visual content, and so are logotypes, which means text that is part of a logo or brand name.

SC 1.4.11 exempts graphics whose exact presentation carries the meaning, which covers logos, flags, photos of real scenes, screenshots, medical diagrams and heat maps (W3C Understanding docs).

The inactive exemption is literal. A control that still works but is styled gray to look secondary is active, so it needs the ratio.

Where the logo exemption stops

The logo is exempt, but that doesn’t stretch to the rest of the brand palette.

A logo that works as a link or button counts as a UI component, so W3C recommends a variant with enough contrast or a second control that has it.

A logo faded by author choice isn’t covered either. W3C’s example shows dark gray logos on a black strip that turn white on hover, and that default presentation fails because nothing in the brand identity requires it.

When a passing ratio still fails

Thin type is one case. Anti-aliasing can render thin strokes fainter than the CSS color, so a pair that nominally passes reads weaker on screen.

W3C’s advice is sturdier strokes or a margin above the minimum, which makes typeface choice part of accessible typography as much as color choice.

Text over images has no single background color. A headline laid over a hero image changes its ratio letter by letter, and failure F83 covers exactly that case.

A quick check is to compare dark text with the darkest area of the image, or light text with the lightest area. If that clears the ratio, the failure does not apply. If it doesn’t, test the background behind each letter against that letter.

Gradients follow the same logic. Measure the least contrasting region, because that is where the text gives out first.

How do you check and fix color contrast?

Start by measuring the exact foreground and background values with a checker. Shift the failing color until the pair clears its threshold, then re-test every state. Automated scans find the easy failures, but text over images and gradients still needs a manual look.

Checking contrast with a tool

Lighthouse lists contrast failures per page inside the same DevTools workflow, so one scan covers the whole document.

Design files can be checked before any code exists. Figma’s Color Contrast Checker takes two hex codes and reports AA and AAA results. It previews color blindness types too, and it passes the adjusted palette back to Figma Design.

One rounding difference matters for bold text. axe counts 14pt bold as large at 19 CSS px, while W3C’s conversion gives about 18.5px, so bold text between those sizes gets the stricter ratio in axe.

Fixing a failing color pair

Start with body text, then move to links and buttons, and leave form field borders and icons for last. Body text covers the most pixels and the most readers.

1. Read the specified colors from the stylesheet or design file, not from a screenshot, because anti-aliasing alters on-screen pixels.
2. Pick the threshold for the element type: text, large text or UI component.
3. Shift the lightness of one color and hold its hue. WebAIM’s checker has a lightness slider, and DevTools offers a suggested color at the AAA level.
4. Re-measure every state (default, focus, selected, and any custom hover), since none may lose contrast against its adjacent colors.
5. Record the passing pair as a token.
6. Review by eye what automation skips.

When no existing color passes, an accessible color palette generator can supply candidates to test.

Store each passing pair once in a design system so later pages inherit it instead of re-testing it.

Set both colors together. W3C treats a text color without a background color, or the reverse, as failure F24, because the user’s default background cannot be evaluated.

Will APCA replace the WCAG contrast ratio?

No published standard has replaced it. WCAG 2.2 is the current W3C Recommendation, and the WCAG 3.0 Working Draft dated 10 September 2026 still lists its contrast algorithm as yet to be determined.

How APCA reads a color pair

The Accessible Perceptual Contrast Algorithm, developed by Andrew Somers through Myndex, reports an Lc (lightness contrast) value tuned to how people perceive lightness differences.

Its documentation sets example targets for body text, based on Helvetica or Arial. Lc 90 is preferred for body columns at 14px and up in normal weight. Lc 75 is the minimum for body columns at 18px and up in normal weight, and Lc 60 is the minimum for other content text, such as 24px regular or 16px bold.

The project also argues that a single ratio overstates contrast for dark colors, which makes WCAG 2 a weak fit for dark mode. That is the project’s own claim, and its dark mode guidance is labeled preliminary.

Where the sources disagree

Several consultancy and agency posts say WCAG 3.0 swaps the 4.5:1 ratio for APCA. The W3C draft says otherwise.

Its contrast text carries a placeholder and an editor’s note that the algorithm is undecided, and it assumes only that the algorithm will include a size and weight factor.

APCA’s own documentation calls it a candidate. Adrian Roselli’s April 2026 write-up explains the gap. APCA was marked for removal in early 2023 and left the July 2023 working draft, because exploratory items without working group support are dropped automatically after six months.

Roselli also warns that advice to drop the WCAG 2 ratio in favor of APCA creates legal risk. He expects WCAG 3 to finish no earlier than 2030, and no W3C date exists, so any timeline is an estimate.

How to use both

Use the WCAG 2.2 ratio for conformance, since it’s the standard the W3C Recommendation defines. APCA works as a second opinion for thin type and light text on dark backgrounds, where the two models can disagree.

Treat an APCA result as advice until the thresholds stop moving. The ratio decides pass or fail.

Color Contrast FAQ

Is color contrast a legal requirement?

Yes, wherever a law points to WCAG. Section 508 incorporates WCAG 2.0 Level AA (US Access Board, 2017), and the ADA Title II rule requires WCAG 2.1 AA with April 2027 and April 2028 deadlines after a 2026 extension (DOJ). In the EU, EN 301 549 V3.2.1 carries WCAG 2.1 AA for web content (W3C WAI). V4.1.1, published on 2 September 2026, moves that baseline to WCAG 2.2 AA, but it only gives a presumption of conformity once it is cited in the Official Journal of the European Union.

Non-text contrast only arrived in WCAG 2.1.

Do the same contrast ratios apply in dark mode?

Yes. The formula divides the lighter luminance by the darker one, so two colors score the same whichever is the text.

Test each theme as its own palette, because switching themes swaps every pair.

Is pure black on pure white the best choice?

It passes at 21:1, but passing only sets a floor. W3C notes that some people with cognitive disabilities need lower-contrast combinations, and AAA criterion 1.4.8 asks for a way for users to choose their own foreground and background colors.

Does color contrast matter in print and graphic design?

The principle applies, but the WCAG thresholds do not formally. WCAG covers web content, and its formula assumes sRGB screens.

W3C did borrow the 18pt and 14pt large text sizes from print guidelines by the American Printing House for the Blind and the Library of Congress.

Where to Start Fixing Color Contrast on a Live Site

Fix color contrast in order of how much text each element carries. Body copy comes first, then links and buttons, then form fields and icons. Body text has the strictest target at 4.5:1 and covers more of the page than anything else.

Body text and captions need 4.5:1, and so do link text and button labels. Form field borders, icons and focus indicators need 3:1.

Lower the lightness of a failing brand color and keep its hue, so the shade still reads as the same brand. The trade-off is a darker value, so keep the original only for decoration, or for large text when it reaches 3:1.

This order holds while WCAG 2.2 is the current Recommendation. As of October 2026 the WCAG 3.0 draft leaves the contrast algorithm undetermined, so a ratio-based audit stays valid.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu specializes in web and graphic design, focusing on creating user-friendly websites, innovative UI kits, and unique fonts.

Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.

Latest posts by Bogdan Sandu (see all)

• What is Backend in Web Development? - September 13, 2026
• What is Frontend Development? - September 11, 2026
• How to Make a Button in Figma: Design Best Practices - September 10, 2026