WCAG-EM 2: The Accessibility Audit Workflow Designers Need

Accessibility audits have a reputation for arriving at the end of a project, carrying a spreadsheet, and asking why the primary button has three different focus states. WCAG-EM 2 offers a more useful frame. Published by the W3C on July 23, 2026, the updated WCAG Evaluation Methodology applies to websites, mobile apps, kiosks, and other digital products, not only web pages. That broader scope gives design teams a practical way to plan reviews before the handoff becomes a small archaeological dig.

WCAG-EM 2 isn't a new set of requirements. It's a method for evaluating how well a product conforms to the existing Web Content Accessibility Guidelines. The distinction matters, especially when a draft standard is being discussed in every conference hallway. Here’s what the new methodology changes for agencies, product teams, and anyone who has ever inherited a Figma file with 147 unnamed frames.

What WCAG-EM 2 actually does

The W3C describes WCAG-EM 2 as a way to assess conformance through either a self-assessment or a third-party evaluation. It’s independent of specific browsers, assistive technologies, and auditing tools. In practical terms, that means the method is a repeatable plan for deciding what to review, which screens or states represent the product, how findings are recorded, and how the results are reported.

The update’s most important change is scope. The original methodology focused on websites and web pages. WCAG-EM 2 includes mobile applications, kiosks, and other digital products, which is a much closer match to how people actually experience a brand. A campaign landing page, an onboarding flow, a mobile checkout, and a self-service kiosk now make more sense as parts of one service rather than four unrelated audit tickets.

There’s a useful reality check in the official WCAG-EM 2 overview: the methodology is intended mainly for evaluating existing products, but accessibility should be built into planning, design, and development from the beginning. The audit is the inspection. It isn’t the entire building code.

The five-step workflow designers should know

1. Define the scope before opening the audit tool

Start by agreeing on the product boundary, the evaluation goal, and the target conformance level, whether that’s Level A, AA, or AAA. For a design team, this turns a vague request for “an accessibility check” into a project decision. Write down the platforms, languages, user journeys, content types, and states in scope. If the modal, empty state, and error message aren’t listed, they have a suspicious habit of disappearing from the review.

2. Explore the whole experience

WCAG-EM 2 asks evaluators to identify key views, functions, content, designs, and technologies. Designers can support this step with a journey map that includes more than the happy path. Add sign-in failures, validation errors, permission changes, loading states, zoomed layouts, keyboard paths, reduced-motion settings, and content created by users or clients.

This is also where teams should identify design dependencies. A color token may appear in a component library, a CMS template, a native wrapper, and a marketing email. Fixing one instance without finding the others is how contrast issues become a recurring subscription.

3. Choose a representative sample

Testing every screen in a mature product may be unrealistic, so WCAG-EM 2 uses a representative sample that combines structured and randomly selected views. The goal isn’t to pick the five prettiest screens for a presentation. It’s to cover the product’s patterns, functionality, content, and technology.

For design leads, a good sample is a map of risk. Include screens with tables, forms, rich media, animation, charts, drag interactions, third-party embeds, and dense navigation. Include at least one route that was built by a different team. The odd corner is often where the system reveals its actual rules.

4. Evaluate and record the evidence

The evaluation step determines which WCAG requirements pass or fail, whether accessibility support is present for specific features, and how the review was conducted. A design review should capture the component, state, user impact, severity, reproduction steps, and a proposed direction. “Make it accessible” is an aspiration, not a handoff note.

For motion and interaction design, record what happens when animation is reduced, paused, interrupted, or triggered by keyboard input. For type, record zoom behavior, line wrapping, focus visibility, and the relationship between text and background. For content, capture the actual copy length rather than the polite placeholder that never survives launch.

5. Report findings as decisions

WCAG-EM 2 ends with aggregated findings and an evaluation statement. Internally, translate that report into decisions the team can act on: which tokens change, which components need a new state, which content rules become mandatory, and which issues block release. Keep the source evidence attached to each decision so the next review doesn’t begin with a debate about whether the issue was ever real.

What this means for agency workflow

• Make scope a design deliverable. Add platforms, journeys, states, and conformance goals to the kickoff deck and the design brief.
• Review patterns, not isolated screens. Test components in context, including long labels, localization, error copy, focus, and responsive layouts.
• Use early checks before a formal evaluation. The W3C’s Easy Checks can catch common barriers before a larger review consumes the schedule.
• Invite people with disabilities into the process. WCAG-EM 2 notes that real users can reveal problems that a checklist misses. A report can verify a focus order. It can’t fully describe the frustration of losing your place in a flow.
• Keep the asset pipeline honest. If you’re exploring placeholder imagery or visual variants during planning, tools such as pixelbrief.ai can help generate options, but every final asset still needs useful alternative text, sufficient contrast, and a clear purpose.

For teams already working in component libraries, the payoff is straightforward. Each recurring accessibility finding can become a token, component rule, content constraint, or test case. That’s more durable than adding a red comment to one frame and hoping it develops legs.

Don’t confuse WCAG-EM 2 with WCAG 3

The W3C is also developing WCAG 3, but it remains an incomplete working draft. The current WCAG 3 introduction says the draft will change, its conformance model is still being developed, and it isn’t expected to become a completed W3C Standard for several years. WCAG 3 also won’t supersede WCAG 2 immediately.

For current project work, use the applicable WCAG 2 requirements and treat WCAG-EM 2 as an evaluation method. Keep an eye on the draft if you’re building a long-lived design system, but don’t turn an unfinished standard into a release blocker. Design teams have enough speculative roadmaps already.

A practical starting point this week

Pick one representative journey and write its scope in plain language. List every view and state, mark the components it uses, and run a short preliminary review with keyboard navigation, zoom, contrast, focus visibility, motion settings, and real content. Then invite a developer and, where possible, a disabled user to review the flow with you.

That small exercise gives the team something better than an audit-shaped surprise at the end of the project. It creates a shared map of the experience, the evidence behind the decisions, and a design system that has to behave in public, not only in the canvas.