Right, let's talk about the elephant in the room: the September 2026 WCAG 3.0 Working Draft. If you've been comfortably resting on your WCAG 2.2 laurels, it's time to wake up, because the W3C just dropped a significant update that fundamentally changes how we think about "compliance."
I've been digging through the 10 September 2026 draft, and while it's still explicitly an "incomplete draft that will change," the direction is clear. We're moving away from a binary pass/fail checkbox and towards a nuanced, tiered system of evidence. As UX engineers managing design systems, this shifts our focus from individual components to holistic user journeys.
The End of the Binary Checkbox
For years, we've treated accessibility like a light switch. Is the contrast 4.5:1? Yes? Then it's accessible. WCAG 3.0 throws that out the window in favour of a weighted scoring model. The new draft uses tags for core requirements: Physical harm, Risk, Barrier, and Friction.
In this model, a defect that causes physical harm or prevents a user from completing a task (a Barrier) is weighted much more heavily than simple Friction. This is a massive win for pragmatism, but it means our design system documentation needs to start tracking these tags at the component level.
{
"component": "modal",
"scope": "view",
"coreRequirements": ["keyboard", "focus-trap", "name-role-value"],
"wcag3Tags": ["Barrier", "Friction"],
"status": "reviewed"
}
Understanding the Tiered Conformance
The September 2026 draft introduces six cumulative tiers. It's not just about reaching "Tier 3 Conformance" (which covers all core requirements); it's about the headroom for Bronze, Silver, and Gold. Here's how the draft breaks it down:
- Tier 1 & 2: Addressing Physical harm, Risk, and Barriers.
- Tier 3 (Conformance): Meeting all core requirements, including Friction.
- Tiers 4-6 (Bronze, Silver, Gold): Adding supplemental requirements and assertions.
What does this mean for your release cycle? You should start categorising your accessibility backlog by these tags. A bug that blocks a checkout process (Barrier) is now a Tier 2 failure, which is far more critical than a decorative icon missing an alt tag (Friction).
From Components to Views and Processes
One of the biggest shifts in the 2026 draft is the concept of scope. WCAG 3.0 conformance claims are scoped to either "views" or "processes." Testing a button in isolation in Storybook is no longer enough to claim conformance.
We need to build journey-level test suites that evaluate complete user flows. If your design system provides a "Checkout Pattern," that pattern must be validated as a complete process. I've found that integrating Playwright or Cypress tests that mimic these full journeys is the only way to stay ahead of this requirement.
// Example: Journey-level test for WCAG 3 'process' scope
await page.goto('/checkout');
await expect(page.getByRole('heading', { name: /payment/i })).toBeVisible();
await expect(page.getByRole('button', { name: /place order/i })).toBeEnabled();
Don't Panic: It's Still a Draft
It's important to remember W3C's own words: "WCAG 3 is currently an incomplete draft that will change." You shouldn't be rewriting your company's legal procurement policies just yet. However, you should be updating your internal design system governance.
I recommend keeping your current WCAG 2.2 checks as the baseline policy while you experiment with the new scoring model. For instance, continue using your existing contrast tokens, but start tagging them for potential WCAG 3.0 transitions.
// Design-token gate for contrast-like requirements
export function meetsCoreTextTokens(fg: string, bg: string) {
// Keep as policy until WCAG 3 guidance stabilizes
return getContrastRatio(fg, bg) >= 4.5;
}
Wrapping Up
- Move from pass/fail to a tiered evidence model based on Physical harm, Risk, Barrier, and Friction.
- Shift your testing focus from isolated components to complete 'views' and 'processes'.
- Start tagging component defects in your backlog to align with the new weighted scoring model.
The September 2026 draft is a glimpse into the future of UX engineering. It’s more complex, yes, but it’s also more human. It forces us to care more about the user's actual journey than a technical spec sheet. Start experimenting with these tiers in your next sprint—you'll thank yourself when the final standard arrives.
If you want to go deeper and learn how to build real, production-ready CSS design systems step by step, check out my full course here: CSS Design Systems Course
I cover the full pipeline in Ship Your Design System, 200 pages on Amazon Kindle.
For more thoughts on CSS architecture and design systems, catch me on Twitter or connect with me on LinkedIn.