WCAG Contrast Ratios Explained: AA vs AAA

Every accessibility audit eventually produces a spreadsheet full of numbers like 3.2:1, 4.51:1, and 6.9:1, with a pass or fail beside each one. Those thresholds are not arbitrary design opinions — each comes from a specific WCAG 2.1 success criterion with a specific scope, and knowing which criterion applies to which element resolves the majority of disagreements between designers and auditors. This post is a close look at the numbers themselves: where they come from, exactly what they cover, and how to decide whether AA is enough for your product.

For the broader picture — how relative luminance is calculated, how color vision deficiency fits in, and how to build an accessible palette from scratch — see The Complete Guide to Accessible Color and Contrast. What follows goes narrow on the ratios.

The four numbers you actually need

WCAG 2.1 sets text contrast in two criteria, and non-text contrast in a third.

Element	Level AA	Level AAA
Normal text	4.5:1	7:1
Large text	3:1	4.5:1
UI components and meaningful graphics	3:1	(no AAA equivalent)

The text rows come from 1.4.3 Contrast (Minimum) at Level AA and 1.4.6 Contrast (Enhanced) at Level AAA. The third row comes from 1.4.11 Non-text Contrast, which is Level AA and has no stricter counterpart — there is no AAA requirement for buttons, borders, or focus rings.

Notice the pattern: the AAA large-text threshold (4.5:1) is exactly the AA normal-text threshold. That is deliberate. Increasing text size buys you one step down the scale, and increasing conformance level buys you one step up.

Where 4.5:1 and 7:1 come from

The numbers look like round design choices but are derived from vision research, and the derivation explains their scope.

WCAG's understanding documents start from a baseline of roughly 3:1, the contrast level widely used as the minimum for readable text by people with normal vision — it is the value referenced in ANSI standards for legible print. The AA threshold then applies a compensation factor of about 1.5 to that baseline, targeting users with visual acuity around 20/40. That level of acuity is typical of someone around age 80, or of a younger person with mild uncorrected vision loss. 3 × 1.5 = 4.5.

The AAA threshold applies a larger factor of about 2.3, targeting roughly 20/80 acuity — the point at which someone is generally considered to have low vision but is not using assistive magnification. 3 × 2.3 ≈ 7.

Two things follow from this. First, the thresholds are about contrast sensitivity loss, not about color perception, which is why they are identical for every type of color vision deficiency. Second, they assume the user has not enabled magnification or a high-contrast mode; the criteria exist so that the default rendering is usable without assistive intervention.

The large-text allowance has its own rationale. Larger glyphs have thicker strokes and more area, and stroke width is a strong driver of perceived contrast. WCAG compensates by dropping the requirement one step rather than defining a separate formula.

The large-text definition trips almost everyone

"Large text" under WCAG 2.1 means:

• 18pt or larger — 24px at default browser settings, or
• 14pt or larger when bold — 18.66px bold

The most common mistake is treating 16px body copy as large because it is the browser default. It is not. 16px normal-weight text must clear 4.5:1 at AA, full stop. An 18px heading is still normal text. A 20px bold subheading qualifies as large; a 20px regular-weight subheading does not.

Two secondary traps:

• Point-to-pixel conversion assumes a default root size. If your CSS uses rem and the user has increased their base font size, the rendered size grows, which only helps. But if your design system defines sizes in pt for print and px for screen, verify the screen value rather than the print value.
• Bold is a weight threshold, not a stylistic one. The bold allowance is intended for genuinely heavy weights. A 14pt font at weight 500 is not reliably bold; weight 700 is.

When you check a pair in the Contrast Ratio Checker (WCAG AA/AAA), it reports the measured ratio against all four text thresholds simultaneously, so you can see at a glance whether a color works for body copy, for headings only, or not at all.

What 1.4.11 covers, and what it does not

Non-text Contrast is the criterion most teams fail without noticing, because visual designers instinctively make borders subtle. It requires 3:1 against adjacent colors for two categories:

User interface components. The parts of a control needed to identify it — the border of a text input, the outline of an unchecked checkbox, the track and thumb of a toggle, and focus indicators. Note "the parts needed to identify it": a button with a solid filled background is identified by that fill, so the fill needs 3:1 against the page, but a decorative inner shadow does not.

Graphical objects required to understand content. Chart lines and series, meaningful icons, diagram strokes, and map boundaries. A decorative background illustration is exempt. An icon that duplicates adjacent visible text is also exempt, because the text carries the meaning.

What 1.4.11 does not cover: text (that is 1.4.3), pure decoration, inactive controls, logotypes, and elements whose appearance is determined by the browser rather than the author, such as default system checkboxes you have not restyled.

Choosing your target level

For nearly every product the answer is AA, and this is a legal fact rather than a preference. EN 301 549, the European accessibility standard referenced by the European Accessibility Act, points at WCAG Level AA. Section 508 in the United States incorporates WCAG 2.0 Level AA. Public-sector procurement rules in most jurisdictions do the same. AAA appears in almost none of them.

WCAG itself is explicit about why: its conformance section notes that it is not possible to satisfy all Level AAA criteria for some content, and advises against requiring AAA as a general policy. Some AAA criteria are genuinely impractical — a 7:1 requirement rules out a large portion of usable mid-tone palettes, and colored brand elements become very difficult to preserve.

That said, AAA text contrast is worth targeting selectively:

• Long-form reading surfaces — documentation, articles, legal text, anything a user reads for more than a minute
• Products with an older user base — healthcare portals, benefits systems, banking
• Environments with glare — kiosks, in-vehicle screens, field tools used outdoors

A pragmatic policy that many design systems adopt: hit AA everywhere as a hard gate, and hit AAA for body text specifically, where the extra cost is one darker gray token rather than a palette rework. If your current body color falls between 4.5:1 and 7:1, the Accessible Color Pair Finder will generate the nearest variants of your existing color that clear the higher threshold, which usually means a small lightness shift rather than a new hue.

Margin matters more than the exact number

A pair measuring 4.5:1 conforms. A pair measuring 4.5:1 is also fragile, for three reasons:

1. Checkers round differently. One tool showing 4.50 and another showing 4.49 is a rounding artifact, not a disagreement about the color, but it will still show up as a failure in someone's report.
2. Anti-aliasing lowers effective contrast. Sub-pixel rendering blends edge pixels toward the background. At small sizes and thin weights, a measured 4.5:1 delivers less than 4.5:1 of perceived edge contrast.
3. Colors drift. Someone will nudge a token, apply an opacity, or place the text on a slightly tinted surface, and a zero-margin pair immediately fails.

Target 5:1 or better for anything under 16px, and treat 4.5:1 as the floor rather than the goal. If you inherit a palette that sits right at the line, How to Fix Failing Color Contrast on Your Site walks through the lightness-first repair process that preserves brand hue while creating headroom.

Where the ratios stop helping

Contrast ratios measure luminance difference and nothing else. They cannot tell you whether two chart series in different hues at the same lightness are distinguishable — they will both pass against the background and be identical to a user with deuteranopia. That gap is covered by criterion 1.4.1 Use of Color at Level A, and by simulation rather than measurement; Designing for Color Blindness: A Practical Guide covers what to do about it.

The practical division of labor: use ratios to confirm text is legible, use simulation to confirm information is decodable, and use the WCAG Accessibility Compliance Checker on assembled screens to catch the pairs that emerged from overlays, hover states, and translucent surfaces rather than from your token list. Everything runs in the browser, so unreleased screens and internal palettes never leave your machine.