Skip to content
wcagc
Create account
←Back to blog
EN 301 549testingAnnex CWCAG-EMEAA

How to test for EN 301 549 conformance

EN 301 549 testing in practice: scope the clauses that apply, sample with WCAG-EM 2.0, run the Annex C tests, and record Pass, Fail or N/A.

P

Pavel Charkasau

EN 301 549 testing comes down to five steps. Decide which clauses apply to your product, pick a sample of screens and flows to test, run the Annex C test for each applicable clause on that sample, use people and assistive technology for the tests a tool can't decide, and record one result per clause. The standard gives you the per-clause tests. It doesn't give you the sampling method, and says so: clause 14 states that sampling is "frequently required on complex ICT" but that the standard "cannot recommend specific ICT evaluation sampling techniques as these are context specific" (ETSI EN 301 549 v3.2.1, clause 14, Note 2). For the web, most teams fill that gap with W3C's evaluation methodology, WCAG-EM, which reached version 2.0 as a W3C Group Note on 23 July 2026 (W3C WCAG-EM 2.0).

This guide is about running the tests. Writing them up is a separate job, covered in our post on the EN 301 549 conformance report.

What does EN 301 549 testing actually check?

Every requirement in EN 301 549 starts with a pre-condition, "Where ICT ...", and Annex C pairs it with a test. A requirement applies only when its pre-conditions are true. Conformance means meeting all the applicable requirements (ETSI EN 301 549 V4.1.1, clause 14.1).

Each Annex C entry has the same fields: type of assessment, requirement pre-conditions, procedure, and result. Here is the one for contrast on a web page, clause C.9.1.4.3:

  • Pre-condition: "The ICT is, or includes, a web page."
  • Procedure: "Check that the web page does not fail WCAG 2.2 Success Criterion 1.4.3 Contrast (Minimum) according to WCAG Conformance Requirements stated in clause 9.6."
  • Result: Pass, Fail, or Not applicable if the page has no content relevant to 1.4.3.

V4.1.1 calls these tests "sufficient", and adds that "other testing approaches can be used if justified" (ETSI EN 301 549 V4.1.1, clauses C.1 and 14.1). That leaves room for your own method, as long as you can explain it.

Which clauses do you need to test?

Only the ones whose pre-conditions are true for your product. For a typical SaaS product, that sorts out roughly like this:

Part of the productClausesNotes
Web app and marketing site9 (web)WCAG A and AA, plus 9.6 conformance requirements
PDFs and downloadable files10 (documents)Invoices, reports, exported files
Native desktop or mobile app11 (software)Web views inside a native app go here too in V4.1.1
Help centre, support channels, product docs12Clause 12 isn't self-scoping in v3.2.1
Video player, calls, kiosk hardware6, 7, 5, 8Only if you have those features

Clause 4, the functional performance statements, sits over all of it. The Chapter 9 explainer goes through the web clauses one by one.

Write the scope down before you start. Which domains, which apps, which document types, which version of the standard. Since September 2026 there have been two versions in circulation. v3.2.1 (WCAG 2.1) is still the one cited in the Official Journal, and V4.1.1 (WCAG 2.2) is published but not yet cited (AccessibleEU). Name the version in your test plan. A result without a version is hard to defend later.

How do you pick a sample of pages to test?

Use WCAG-EM 2.0 for web content. Its five steps are: define the evaluation scope, explore the product, select a representative sample, evaluate the sample, and report the findings (W3C WCAG-EM 2.0). The sampling step has three parts:

  1. A structured sample. The common views (header, footer, navigation), each distinct type of page or screen, and the essential functionality, such as sign-up or payment.
  2. A random sample. WCAG-EM sets it at "10% of the structured sample set". If your structured sample is 80 views, you add 8 random ones.
  3. Complete processes. Every step of each key flow, start to finish.

The random sample is a check on yourself. WCAG-EM says that if the random pages turn up new types of content or new kinds of failures, your structured sample "was not sufficiently representative" and you go back and widen it.

WCAG-EM also says that if you can evaluate the whole product, you can skip sampling. For a 30-page site, test everything.

One more scoping rule from WCAG-EM: don't carve parts out. It calls this "full product enclosure", and says excluding parts of the product would likely conflict with the WCAG conformance requirements for full pages and complete processes. V4.1.1 says the same thing about third-party additions. Clause 14.1, Note 3: if a site incorporates "an add-on, overlay, or other" component, that combination is what gets evaluated (ETSI EN 301 549 V4.1.1). Your cookie banner and chat widget are in the sample.

How do you run the Annex C tests?

Annex C labels each test with a type of assessment. I counted them in V4.1.1. Most are "Inspection", meaning a person examines the product and checks it against the requirement. A smaller set are "Testing" or "Measurement", mostly in the general, hardware and software clauses (5, 8 and 11). Clause C.5.1.3.1, for example, asks the tester to confirm all closed functionality is "operable using audio output access" (ETSI EN 301 549 V4.1.1, Annex C).

For a website, in practice, I'd run each sampled view through this order:

  1. Automated scan. Clears the machine-checkable failures: missing alt, contrast ratios, missing form labels, duplicate id values, invalid ARIA attributes.
  2. Keyboard pass. Tab through the page with no mouse. Is focus visible on every control? Does it get trapped in the date picker? Can you reach and close the modal?
  3. Screen reader pass. NVDA with Firefox or Chrome on Windows, VoiceOver with Safari on macOS and iOS. Listen to what a button announces. "Button" alone fails 9.4.1.2. Our screen reader testing guide covers the setup.
  4. Display checks. Zoom to 400% for reflow (9.1.4.10), apply the text-spacing values from 9.1.4.12, and turn on forced colours, which matters for V4.1.1 clause 9.7.
  5. Content judgement. Is the alt text accurate, the heading text meaningful, the error message useful? Only a person can answer these.

Then repeat the keyboard and screen reader passes across each complete process. A checkout that passes page by page can still fail 9.6 if step three resets the form and drops focus to the top of the document.

How much of EN 301 549 can an automated tool test?

A minority of it, and you should plan the budget around that. Deque's 2021 study of more than 2,000 of its own audits found automated tests identified 57% of issues by volume. The same post contrasts that with the older belief of 20 to 30% coverage, which counted WCAG success criteria rather than the volume of issues found (Deque). Both numbers are about web content. For documents, software and hardware the share is lower, and some Annex C tests, like the audio-output one above, can't run in a browser at all.

W3C says the same thing in WCAG-EM 2.0: "most accessibility checks are not fully automatable", though tools "can significantly assist evaluators", for example by crawling a product to find samples for manual review (W3C WCAG-EM 2.0).

This is my view, plainly: a scanner is the first pass of an EN 301 549 test, never the whole test. We built ours to show the exact selector and the clause for each failure because that is the part a machine does well. It won't tell you whether your error messages make sense. And an overlay widget doesn't shortcut any of this. Under V4.1.1 it is simply one more component in the sample.

How do you record EN 301 549 test results?

One result per clause per sample, using the standard's vocabulary. v3.2.1 lists four possible outcomes: "not applicable, pass, fail, or (in exceptional circumstances) not testable" (ETSI EN 301 549 v3.2.1, clause 14). V4.1.1 renames the fourth: "Test assumptions are not met", meaning this test can't be used and you need another way to test that clause.

"Not applicable" is a real result, not a dodge. Annex C defines it. A page with no video passes nothing and fails nothing on captions; the clause doesn't apply. Record it that way.

For each failure, write down what a developer needs: the page or screen, the selector or component, the clause, the observed behaviour, and the assistive technology and browser versions you used. "9.2.4.7 fails on /checkout/payment, button.card-toggle has outline: none and no replacement focus style, Chrome 141" can be fixed. "Focus issues on checkout" can't.

WCAG-EM 2.0 asks you to document the outcome of every step, the scope and sample included, though it notes that documentation "does not need to be public" (W3C WCAG-EM 2.0). This record is what your accessibility statement and conformance report are built from. Under the European Accessibility Act, it is the evidence behind what you claim. Clause 14.1 also has a note worth taking seriously: conformance "could be affected by subsequent implementation or maintenance". A test result describes the build you tested, so plan to re-test after releases.

Frequently asked questions

Does EN 301 549 tell you how to sample pages?

No. Clause 14 says the standard "cannot recommend specific ICT evaluation sampling techniques" because they depend on context. For web content, W3C's WCAG-EM 2.0 is the usual method: a structured sample, a random sample of 10% on top, and every complete process.

Can an automated scan prove EN 301 549 conformance?

No. A scan settles the machine-checkable tests, which Deque puts at 57% of issues by volume at best. Most Annex C tests are inspections that need a person, and full conformance needs human review with a keyboard and assistive technology.

Which version of EN 301 549 should I test against?

v3.2.1 is the version cited in the Official Journal today, so it is the legal reference. V4.1.1 adds WCAG 2.2 and clause 9.7. Name the version in your test plan; testing against V4.1.1 now covers almost everything v3.2.1 asks for, except 9.4.1.1 Parsing, which only v3.2.1 still lists.

Do I have to test third-party widgets?

Yes. V4.1.1 clause 14.1 says an add-on or overlay becomes part of the ICT, and the combination is evaluated. WCAG-EM's full-pages rule leads to the same place for chat widgets, embedded payment forms and cookie banners.

What does "Not applicable" mean in an Annex C result?

It means a pre-condition of the requirement is false, so the clause doesn't apply. A page with no pre-recorded video is Not applicable for the captions clause. Annex C defines it as a valid outcome.

Start with the machine-checkable layer

Run a free scan on your sampled pages to clear the automated part of the Chapter 9 tests, with the selector for each failure. Then work through the manual checks with the WCAG checklist, keyboard first and screen reader second, and record a result for each clause. The scan is the start of an EN 301 549 test; the human review is what finishes it.

Pavel Charkasau, founder, wcagc.com. Last updated 16 October 2026.

Sources