The W3C dropped a fresh WCAG 3.0 working draft on March 3rd, and buried in the 174 new outcomes is a quiet bombshell: the contrast algorithm your design system relies on is being replaced. APCA — the Advanced Perceptual Contrast Algorithm — doesn't just tweak the numbers. It fundamentally changes which color combinations pass and fail, and your carefully audited token palette is caught in the crossfire.

The ratio you memorized is dead

For years, the magic number was 4.5:1 for normal text, 3:1 for large text. Simple. Binary. A color pair either passed or it didn't, regardless of font size, weight, or whether the text sat on a dark background or a light one.

APCA throws all of that out. Instead of a ratio, it produces a Lightness Contrast (Lc) value on a scale from roughly 0 to 108. The required Lc depends on context — body text at 16px might need Lc 75, while a bold 24px heading could get away with Lc 45. And here's the part that trips people up: APCA is asymmetric. White text on dark blue scores differently than dark blue text on white. That's because human perception is asymmetric — we're more sensitive to dark text on light backgrounds than the reverse. The old algorithm pretended polarity didn't matter. APCA doesn't pretend.

This means the pass/fail lookup table living in your Figma linting plugin, your CI accessibility checks, and your design token documentation needs rethinking. Not next year. Now, while the spec is still in draft and you can influence your system's architecture before it calcifies.

Bronze, Silver, Gold — goodbye letter grades

WCAG 3 also kills the A/AA/AAA tier system. In its place: Bronze (roughly today's AA baseline), Silver (genuinely good accessibility), and Gold (aspirational, covering cognitive disabilities and complex interaction patterns). The twist is that Bronze isn't pass/fail per guideline anymore. Your product gets scored across all outcomes, and you need a minimum average plus zero failures on critical items. Partial credit exists now. That changes the conversation from "we pass AA" to "we score 78% toward Silver" — which is both more honest and harder to game.

What actually breaks in your token stack

I pulled up a common design system setup — neutral gray palette, brand blue, semantic success/warning/error tokens — and ran the values through both WCAG 2.x ratios and APCA Lc scores. The surprises were instructive.

Gray-500 on white passes WCAG 2 AA (4.6:1) but fails APCA for body text. APCA's perceptual model is harsher on mid-grays at small sizes. That "accessible gray" you've been shipping for placeholder text? Under APCA, it doesn't clear the bar for anything below 18px regular weight. Every design system I've worked with has at least one gray like this — technically compliant today, perceptually inadequate tomorrow.

Dark mode gets easier. Light text on dark backgrounds was always awkward under WCAG 2 because the algorithm treated both polarities identically. APCA's asymmetry actually relaxes requirements for dark mode in several cases. Colors that technically failed the 4.5:1 ratio may score a passing Lc when used as light-on-dark. If you've been forcing overly bright whites in dark mode to hit the ratio, APCA might let you dial the brightness back to something less eye-searing.

Semantic colors need weight-aware tokens. Because APCA ties the required threshold to font size and weight, a single --color-error token isn't sufficient anymore. Error text in a form label (14px, regular) demands higher contrast than error text in a banner heading (20px, bold). Your tokens may need to encode typographic context, not just a hex value.

Here's what a weight-aware token structure might look like using the DTCG format:

{
  "color": {
    "error": {
      "default": { "$value": "#dc2626" },
      "on-surface": {
        "body": { "$value": "#b91c1c", "$description": "Lc 78 — validated for 14px/400+" },
        "heading": { "$value": "#dc2626", "$description": "Lc 58 — validated for 20px/700+" },
        "large-display": { "$value": "#ef4444", "$description": "Lc 42 — validated for 32px/700+" }
      }
    }
  }
}

Instead of one error red that "passes," you need a family of reds tuned to their typographic context. Multiply that across your entire semantic palette — error, warning, success, info, plus brand colors — and you're looking at a 3-4x token expansion in the color layer alone. That's not trivial. It touches Figma libraries, style dictionaries, CSS custom property sheets, and every component that consumes them.

Preparing without panicking

The spec isn't final. W3C says Candidate Recommendation is 2027 at the earliest, full Recommendation likely 2028–2030. You have time. But "wait and see" is a trap if you're building or refactoring a design system today, because retrofitting contrast-aware tokens into an existing architecture is significantly harder than designing them in from the start.

Four things worth doing right now:

Dual-audit your palette. Run existing tokens through both WCAG 2.x ratios and APCA Lc values. Flag every combination where results diverge — those are your migration risks. The SAPC-APCA npm package makes this scriptable in CI.

Add font context to token docs. Even if you don't restructure tokens yet, start documenting which sizes and weights each color is validated for. This metadata costs nothing now and saves weeks during migration.

Watch the April timeline. The AG Working Group is publishing a projected WCAG 3 timeline this month. That'll signal how fast Bronze conformance claims become meaningful in procurement contracts and legal contexts — which is what actually forces organizational adoption.

Don't drop WCAG 2.x compliance. APCA is the future, but 2.1 AA is the present legal standard in most jurisdictions. Run both checks during the transition period. Passing APCA while failing 2.x ratios won't help you in court.

The real shift underneath

Design systems sold accessibility as a solved problem — pick from the approved palette, drop it into Figma, ship. WCAG 3 and APCA reintroduce nuance that the old binary system papered over. Contrast depends on context now, which is messier but more honest about how humans actually read screens. The tooling will catch up. Figma plugins that score APCA are already appearing. Style Dictionary transforms can generate weight-aware token sets from a single source. But the conceptual shift — from "this color is accessible" to "this color is accessible at this size and weight" — that's on you to internalize before the spec lands.