Operationalise WCAG-EM 2.0 in Design Systems

We've all been there: a week before a major release, the accessibility audit comes back with 40 'critical' issues. It's a mad scramble of hotfixes, duct-taped ARIA labels, and frustration. We treat accessibility like a final hurdle rather than a core engineering requirement. But what if we could turn that chaos into a repeatable, predictable machine?

On 23 July 2026, the W3C published WCAG-EM 2.0 as a W3C Group Note. It’s an updated, informative evaluation methodology for assessing how digital products conform to WCAG 2. The most exciting part for us? It explicitly broadens the scope from just 'web pages' to apps and other digital products. It’s the perfect framework for senior teams to move away from ad-hoc bug fixing and toward a systemic audit flow.

It’s a Methodology, Not a Standard

One common misconception I've encountered is that WCAG-EM adds new rules you have to follow. It doesn't. As the W3C states, "WCAG-EM does not define additional WCAG requirements." Instead, it provides a step-by-step process for defining scope, exploring the product, selecting samples, and reporting findings.

For design system teams, this is a goldmine. It gives us a professional, industry-standard way to prove our components work across different contexts. Let's look at how we can operationalise each stage of the WCAG-EM 2.0 methodology.

1. Defining the Scope (The Audit Intake)

The first step in WCAG-EM is defining what you're actually testing. In a design system context, I've found it incredibly useful to create a reusable audit intake template. This ensures every audit—whether it's for a new 'Data Table' component or a full 'Checkout' flow—starts from the same baseline.

# accessibility-audit-baseline.yml
product: our-design-system
conformanceTarget: WCAG 2.2 AA
scope:
  browsers: ["Chrome", "Firefox", "Safari"]
  assistiveTech: ["NVDA", "VoiceOver", "TalkBack"]
sampleSets:
  structured: ["button", "dialog", "textfield", "table"]
  flows: ["user-onboarding", "settings-update"]
reporting:
  output: ["markdown", "jira-tickets"]

By documenting the accessibility support baseline (the specific browser and AT combinations you support), you eliminate the 'it works on my machine' arguments that plague accessibility discussions.

2. The Structured Sample: Component Inventories

WCAG-EM 2.0 asks for a representative sample. In a monolithic app, that’s hard to find. In a design system, your component library is the sample. Every variant, state (hover, focus, disabled, error), and breakpoint of a component should be part of your 'structured sample'.

I like to use component checklists during the development phase to ensure we're hitting the marks before the formal audit even begins. Here's a quick example for a Checkbox component:

// component-checklist.ts
export const checkboxChecklist = [
  'label programmatically associated',
  'space toggles state',
  'focus visible',
  'error text announced via aria-describedby',
  'disabled state conveyed to screen readers',
];

3. The Workflow Sample: Complete Processes

WCAG-EM 2.0 isn't just about static views; it's about complete processes. This means testing the full journey: sign-up, checkout, or error recovery. If a user can start a task but can't finish it because the 'Confirm' button isn't reachable via keyboard, the product fails.

We can automate the 'low-hanging fruit' of these workflows using CI gates. While automated tools like Axe can only catch about 30-40% of issues, they are essential for preventing regressions in our representative samples.

// CI gate for critical violations
import { chromium } from 'playwright';
import AxeBuilder from '@axe-core/playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('http://localhost:3000/components/dialog');

const results = await new AxeBuilder({ page }).analyze();
const critical = results.violations.filter(v => v.impact === 'critical');

if (critical.length > 0) {
  console.error('Accessibility violations found!');
  process.exit(1);
}

Common Pitfalls to Avoid

Treating it as a checklist: WCAG-EM is a methodology, not a list of new rules. Use it to structure your process, not to find new things to fail on.
Auditing only 'Happy Paths': The methodology requires a representative sample. You must test error states, empty states, and complex interactions.
Missing the reporting baseline: WCAG-EM expects you to document the scope so another evaluator could reproduce your findings. Don't just list bugs; list the environment they were found in.

Wrapping Up

Use WCAG-EM 2.0 to define a standard audit intake for all digital products, not just web pages.
Map findings back to your design system components to ensure a single fix propagates across the whole product.
Automate the representative sample testing in your CI pipeline to catch regressions early.

I'd encourage you to try drafting your next audit scope using the WCAG-EM stages. It might feel like extra paperwork at first, but the clarity it brings to your engineering team is well worth the effort.

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

If you want the long-form version of this with 23 chapters and runnable code, Ship Your Design System on Amazon is the handbook.

Let's keep the conversation going. I'm always happy to chat about accessibility and design systems on Twitter or LinkedIn.

Post not found