WCAG Contrast Requirements for Typography

Contrast is the single most commonly failed WCAG success criterion in automated accessibility audits. A WebAIM survey of the top one million home pages consistently finds that low contrast text affects the majority of tested pages — in the 2024 survey, 81% of pages had detected contrast failures. For most web developers, contrast feels like a solved problem: pick dark text on a light background and move on. In practice, the rules are more nuanced, and the common shortcuts — muted placeholder text, thin-weight headings, light-colored secondary labels — are where sites routinely fail.

This guide explains exactly how WCAG contrast requirements work for typography, how to test them, how to fix common failures, and how to think about contrast as a design quality rather than just a compliance checkbox.

Understanding Contrast Ratios

The WCAG contrast ratio is a mathematical relationship between two colors expressed as a ratio from 1:1 (no contrast — identical colors) to 21:1 (maximum contrast — pure black on pure white). The formula is:

Contrast Ratio = (L1 + 0.05) / (L2 + 0.05)

Where L1 is the relative luminance of the lighter color and L2 is the relative luminance of the darker color. The 0.05 offset prevents division by zero and represents the ambient light that exists even in a fully dark room.

Relative luminance is itself a calculated value. It accounts for the nonlinear way human vision perceives brightness — our eyes are much more sensitive to changes in dark tones than in light tones. The formula converts sRGB color values through a gamma correction step, then weights the resulting linear values by how much each channel contributes to perceived brightness (green contributes the most, blue the least):

L = 0.2126 × R + 0.7152 × G + 0.0722 × B

Where R, G, and B are the linearized (gamma-corrected) color channel values.

You do not need to calculate this by hand. Every accessibility tool handles the math. What you do need to understand is what the resulting ratio means:

• 1:1 — No contrast at all. Invisible.
• 3:1 — Minimum for large text (AA) and UI components.
• 4.5:1 — Minimum for normal text (AA).
• 7:1 — Enhanced text contrast (AAA).
• 21:1 — Maximum possible (pure black on pure white).

Pure black (#000000) on pure white (#ffffff) achieves exactly 21:1. The very dark charcoal (#1a1a1a) many designers prefer over full black achieves about 17.9:1 — well above the 7:1 AAA threshold. Moving to a medium gray like #767676 on white gives exactly 4.54:1, barely passing AA for normal text but leaving no headroom for rendering variation across devices.

WCAG AA vs AAA Requirements

WCAG 2.x defines two levels of contrast conformance for text:

Success Criterion 1.4.3 — Contrast (Minimum) — Level AA

This is the standard most organizations target. It requires: - 4.5:1 for "normal" text (smaller than 18pt/24px regular weight, or smaller than 14pt/18.67px bold weight) - 3:1 for "large" text (at least 18pt/24px regular, or at least 14pt/18.67px bold)

Success Criterion 1.4.6 — Contrast (Enhanced) — Level AAA

The stricter standard, required for AAA conformance: - 7:1 for normal text - 4.5:1 for large text

Most public-facing organizations target AA conformance. Government agencies and healthcare providers often aim for AAA. Even if you are only required to meet AA, designing toward AAA ratios for body text is a good practice — 7:1 body text is meaningfully more comfortable to read than 4.5:1, especially for users with low vision who do not use screen magnification.

There are explicit exemptions from contrast requirements:

• Decorative text: Text that is purely decorative, provides no information, and is not readable has no contrast requirement.
• Logotypes: Text that is part of a logo or brand name is exempt, though good logos generally have high contrast anyway.
• Inactive UI components: Disabled form fields and buttons are exempt, but they must be perceivable as disabled (not just low-contrast).
• Incidental text in images: Text within photographs or screenshots is exempt, though you should still try to ensure legibility.

These exemptions are frequently misapplied. A placeholder text in an input field that provides instructions is not decorative — it has a communicative function and must meet contrast requirements. A "disabled" button that is merely styled to look muted but is still interactive must meet contrast requirements.

Large Text Exception: What Qualifies?

The large text exception — 3:1 instead of 4.5:1 — is one of the most misunderstood parts of WCAG typography requirements. Developers often apply it too liberally, reducing contrast on elements that do not actually qualify.

To qualify as "large text" under WCAG 2.x: - Regular weight: At least 18 point (pt) or 24 CSS pixels - Bold weight: At least 14 point (pt) or approximately 18.67 CSS pixels

The point-to-pixel conversion used in WCAG is 1pt = 1.333px (at 96dpi, the CSS reference pixel). This means: - 18pt = 24px (regular) - 14pt = ~18.67px, rounded to 19px (bold)

/* This qualifies as large text — 3:1 contrast ratio allowed */
h1 {
  font-size: 2rem;    /* 32px at default — qualifies */
  font-weight: 400;   /* Regular weight: need 24px+ */
  color: #767676;     /* 4.54:1 on white — still passes */
}

/* This does NOT qualify as large text */
.subtitle {
  font-size: 1rem;    /* 16px — does not qualify */
  font-weight: 400;
  color: #767676;     /* Still needs 4.5:1 */
}

/* This qualifies as large bold text */
.cta-label {
  font-size: 1.25rem; /* 20px — qualifies when bold */
  font-weight: 700;   /* Bold weight: need only ~18.67px */
  color: #767676;     /* 4.54:1 on white — passes even at large text threshold */
}

Critical nuance: font weight is part of the classification. A 20px element styled font-weight: 300 (Light) does not qualify as large text — you need regular weight or heavier. And a variable font set to weight 350 is a judgment call — WCAG does not define a precise threshold for "bold," but 700 is universally accepted as bold, and most tools treat 600+ as bold for this purpose.

Also important: the font-size in CSS is not the same as the visual appearance of the text. A condensed font at 24px may appear visually smaller than a wider-proportioned font at 20px. WCAG uses the CSS font-size value, not visual impression, for classification.

Testing Contrast Programmatically

Manual color picking is necessary but insufficient for accessible contrast at scale. You need programmatic testing integrated into your development and CI workflows.

Browser DevTools: Chrome's DevTools displays contrast ratios in the color picker when you click on a color swatch in the Styles panel. Firefox DevTools has an Accessibility Inspector that highlights contrast failures. Both are useful for quick spot-checks during development.

axe-core: The most widely used automated accessibility testing library. Available as a browser extension (axe DevTools), a CLI tool, and a JavaScript library that integrates with Jest, Playwright, and Cypress. It tests for WCAG 2.x contrast failures and provides specific element references and suggested fixes.

# Install axe-cli for command-line testing
npm install -g @axe-core/cli

# Test a URL against WCAG AA
axe https://example.com --tags wcag2aa

Lighthouse: Built into Chrome DevTools and available as a CLI, Lighthouse runs an accessibility audit that includes contrast checking. The scores are useful for tracking progress but note that automated tools can only catch about 30–40% of all accessibility issues — contrast being one of the more reliably detectable categories.

Pa11y: An open-source command-line tool that wraps axe and htmlcs. Useful for CI integration:

npx pa11y --standard WCAG2AA https://example.com

For component-level testing in a design system, you can write contrast assertions directly:

// Using the wcag-contrast package
import { ratio } from 'wcag-contrast';

const contrastRatio = ratio('#767676', '#ffffff');
// Returns 4.54

expect(contrastRatio).toBeGreaterThanOrEqual(4.5); // AA normal text

The key limitation of all automated contrast testing is that it only catches failures where the background color is a solid, computed CSS value. Text on gradients, images, or elements with CSS background-image cannot be tested automatically — those require manual inspection with a color picker tool.

Common Contrast Problems and Fixes

Placeholder text in form inputs: Placeholder text is almost universally too low-contrast. Browser defaults are around 50% opacity of the input text color, which typically produces contrast ratios below 3:1. Placeholder text that provides instructions must meet 4.5:1.

/* Default placeholder — usually fails contrast */
::placeholder {
  color: rgba(0, 0, 0, 0.5); /* ~3.9:1 on white — may fail */
}

/* Accessible placeholder */
::placeholder {
  color: #6b7280; /* #6b7280 on white = 4.61:1 — passes AA */
}

Secondary and muted text: Designs often include secondary text in a lighter color to establish visual hierarchy. Common choices like #9ca3af (gray-400 in Tailwind) produce contrast ratios around 2.5:1 on white — failing for any text size. Solve this with careful color selection rather than abandoning the hierarchy:

/* Common muted text that fails */
.text-muted {
  color: #9ca3af; /* 2.5:1 on white — FAIL */
}

/* Accessible alternative that still reads as secondary */
.text-muted {
  color: #6b7280; /* 4.61:1 on white — PASS */
}

Light-weight typography: Thin and light font weights (100–300) are fashionable in UI design but significantly harder to read at low contrast. A color that passes at weight 400 may be unacceptably difficult to read at weight 200. The WCAG formula does not account for font weight directly, but the perceptual reality is that thin fonts need higher contrast ratios to achieve the same readability.

Dark mode inversions: Automatically inverting colors for dark mode often introduces contrast failures. #222222 text on #1a1a1a background — both dark colors — produces near-zero contrast. Dark mode palettes need independent contrast validation.

Text over images: Hero sections with text over photography are a common source of failures. Solutions include a semi-transparent overlay, a text shadow, or a text container with a solid or blurred background:

/* Semi-transparent overlay approach */
.hero {
  position: relative;
}

.hero::after {
  content: '';
  position: absolute;
  inset: 0;
  background: rgba(0, 0, 0, 0.6);
}

.hero__text {
  position: relative;
  z-index: 1;
  color: #ffffff; /* White on 60% black overlay: high contrast */
}

/* Text shadow approach for shorter text */
.hero__heading {
  color: #ffffff;
  text-shadow: 0 2px 8px rgba(0, 0, 0, 0.8);
}

Link text without underlines: When links are distinguished from surrounding text only by color (no underline), the color difference must meet a 3:1 contrast ratio against the surrounding text — in addition to both the link text and surrounding text individually meeting their contrast requirements against the background. This triple-constraint is often not met by default link styling.

Beyond Compliance: Perceptual Contrast

The WCAG contrast formula, finalized in 2008, has well-documented limitations that its authors have acknowledged. Understanding these limitations helps you make better design decisions even when you are meeting the technical requirements.

Polarity matters: Positive polarity (dark text on light background) is generally more readable than negative polarity (light text on dark background) at the same mathematical contrast ratio. Research suggests that users with certain vision conditions, including astigmatism, find negative polarity more difficult. WCAG does not penalize negative polarity designs, but you may want to apply additional contrast headroom in dark mode.

The formula undervalues chroma: Two colors with the same luminance but different hue saturation — say, a desaturated gray and a vivid chromatic color — produce the same WCAG ratio but may look quite different in terms of readability. High-saturation colored text can sometimes be harder to read than its WCAG ratio suggests.

Font rendering variation: WCAG calculates contrast against specified color values, not actual rendered pixels. Sub-pixel rendering, font smoothing settings, and LCD/OLED display characteristics mean that identical CSS colors can look different on different devices. Design with headroom above the minimum threshold — aim for 5:1 where 4.5:1 is required.

The Accessible Perceptual Contrast Algorithm (APCA) is the proposed replacement for WCAG 3.0. Developed by Andrew Somers, it produces contrast values that better predict readability by accounting for polarity, font weight, and the full luminance range. While not yet a legal standard, many designers are beginning to use APCA values as a supplementary check, particularly for large display text where the WCAG formula is most prone to producing misleading values.

For fonts like Source Sans 3 used at small sizes, or Inter at thin weights, running both the WCAG ratio and an APCA check gives you a more complete picture of whether your contrast choices will actually work for users.

Ultimately, contrast ratios are a proxy measure for readability. The real test is whether real people can read your text comfortably — which is why user testing with people who have low vision, in addition to automated checking, is the gold standard for contrast accessibility.