WCAG-EM 2.0 lets you report on accessibility of more than just websites

WCAG-EM describes a process for checking if a large website conforms to WCAG. More than 10 years after it first came out, WCAG-EM 2.0 updates it to broaden the scope of products it applies to be more than just websites.

It was published by the Accessibility Guidelines Working Group at the W3C—who work on WCAG, among other deliverables, and I was one of the co-editors.

The publication followed after many months of edits, collecting feedback (at IAAP EU, TPAC 2025, and CSUN 2026), processing that feedback, and shepherding new definitions (most notably, “view”).

A process for reporting

The reason my employer cares about it: WCAG-EM is the most commonly used accessibility reporting methodology in The Netherlands. The Dutch government (my team) runs a dashboard that collects conformance reports of thousands of government websites and apps, of which almost all were created by following WCAG-EM. It's used less outside The Netherlands, but my hope is that will change and others find it useful.

WCAG-EM will not tell you how to make a website accessible, it gives you a consistent process to check. WCAG has the requirements, WCAG-EM has steps to report on them. With its sampling process, it helps reliably and consistently report on websites that are too big to evaluate page by page.

If your organisation has many websites, getting your accessibility vendors to use the same methodology could make it easier to understand, compare, and monitor results.

2.0: more than websites

Version 1.0 of WCAG-EM was edited by accessibility veterans Shadi Abou-Zahra and Eric Velleman.

For 2.0, editorship was taken over by myself, Steve Faulkner and Jeroen Hulscher. We did a number of smaller changes: worked on readability and clarity, updating references to related standards and guidance, and adding new graphics and examples.

The most exciting change: we updated terminology so that WCAG-EM can now be applied to apps and other digital products too. This made sense, as regulators have long required apps and other products to be accessible, and WCAG 3 is making a similar shift to broader applicability.

To make this work, we made some changes:

• instead of websites, evaluations now concern digital products
• a “sample of web pages” is now a sample set, we heard from evaluators we talked to that they use the word "sample” as shortcut for web page / view / screen
• a sample can be a web page or any other type of view (app screen, steps in a kiosk etc)
• “web technology” is now just technology

The process itself is mostly the same, and when doing an evaluation you would follow roughly the same steps.

Other changes and future

We also updated:

• the lay-out and underlying spec generation tech (ReSpec, which makes the spec easier to read on small and large screens), and Markdown, for easier future editability, it's all in version control now)
• graphics
• examples (removed jQuery and Dojo, added design systems)
• words (removed unnecessary wordiness, and, thanks to Tamsin Ewing of W3C, we checked it with WCAG 3 style guide)

In the next while, we intend to continue work on WCAG-EM, to make it better aligned with what end users, evaluators, regulators, product teams, and procurers need.

Summing up

It's been great to hear from people how they are using or not using WCAG-EM. If you have thoughts, I'd love to hear them!