Annex C of EN 301 549: what conformance tests look like
Every EN 301 549 requirement has its own test in normative Annex C. A test has four fields (evaluation type, preconditions, procedure, result) and three possible outcomes: passed, failed, not applicable. The standard states it is not a testing methodology: sample selection, tools and reporting are left to the auditor.
Where the tests are
Annex C is titled “Determination of conformance” and mirrors the numbering of the standard’s body. Requirement 9.2.5.8 has its test in C.9.2.5.8, requirement 11.1.4.3 in C.11.1.4.3, and so on. That lets a report follow clause numbers exactly.
The test mechanism is the same in V3.2.1 and V4.1.1. Only the word “functional” dropped out of the scope in the new version; the standard still states that it describes test procedures and evaluation methodology for each requirement.
Anatomy of a single test
| Field | What it contains |
|---|---|
| Evaluation type | Inspection, measurement, examination, or a combination |
| Preconditions | When the requirement applies to the product under test, e.g. “ICT is a website” |
| Procedure | Numbered checks: check 1, check 2 |
| Result | Passed when checks are true; failed when any is false; not applicable when the precondition does not hold |
An example from our discussion, for a requirement on access without speech in closed functionality (e.g. a kiosk where you cannot connect your own assistive technology): the evaluation type is inspection. The precondition is that speech is needed to operate closed functions. The procedure requires checking whether those functions can be started another way, without speech. The result is passed if yes; failed if not; and if the device does not require speech at all, the requirement is not applicable.
Three types of tests
WCAG-based tests (C.9, C.10, C.11). These are short because they refer to the success criterion: the procedure boils down to checking whether the website, document, or program does not violate that criterion. The standard therefore does not describe how to test contrast or focus. Methods come from W3C documents: Understanding WCAG 2.2, Techniques, and for documents and software from WCAG2ICT. We describe new WCAG 2.2 criteria in a separate article.
Measurement-based tests (mainly clauses 6, 7, and 8). These have numeric thresholds. An example is the requirement that video communication provides at least 20 frames per second. For kiosks and ticket machines, height and reach measurements in millimetres apply too.
Documentation and service inspections (clauses 12 and 13). For example, checking whether product documentation describes accessibility features and how to use them.
“Not applicable” is a full-fledged result
Most requirements in the standard start with a “where ICT…” condition, e.g. has video or requires sign-in. That is self-limiting scope. A site with no video cannot violate caption requirements, so those requirements get “not applicable”. In a good report that result is described, not omitted, so the reader knows the requirement was considered.
What the standard does not provide
Already V3.2.1 stated that Annex C defines the means needed to determine conformity with individual requirements but is not a testing methodology. V4.1.1 repeats that disclaimer. The standard therefore does not answer:
- how many and which pages, screens, or documents to examine,
- which tools and assistive technologies to use,
- how to describe a defect, its severity, and how to fix it,
- how to present the result for the whole site.
That is where the auditor’s work begins, and it is what separates a thorough audit from a superficial one. For sample selection, the W3C WCAG-EM method is most often used.
How we run testing: Trop™ model
Our process fills in what the standard does not prescribe:
- Identify ICT type and legal purpose. A website is clause 9, documents 10, apps and web views in apps 11. For the public sector the requirement list comes from Annex ZA, for the EAA from clause A.2.
- Sample selection per WCAG-EM: templates, key processes, random pages. We describe the choice in the report.
- Testing WCAG 2.2 criteria: automated tools as a starting point, then manual tests and screen readers (NVDA or JAWS, VoiceOver, TalkBack).
- Testing requirements outside WCAG: user preferences, multimedia, documentation and support, cooperation with assistive technologies.
- Recording the result for each requirement in the three Annex C values, with evidence: screenshot, URL, and steps to reproduce.
- Linking defects to user groups based on functional performance criteria (clause 4 and Annex B), which helps set repair priorities.
Functional performance criteria in the new version
Clause 4 describes what must be possible for different user groups: without sight, with limited vision, without hearing, with limited manual dexterity, and others. In the new version the name changed from “functional performance statements” to “functional performance criteria”.
Want your team to run conformance tests themselves? Ask about training via contact. Prefer to commission testing? Accessibility PREMIUM includes a full EN 301 549 audit with re-audit.
Frequently asked questions
How do you run an audit aligned with EN 301 549?
Determine which clauses apply to the product, select a sample, test WCAG and non-WCAG requirements, and record each result as passed, failed, or not applicable, with evidence.
Must clause 4 be tested?
Clause 4 describes expected outcomes for user groups; in practice it supports overall assessment and prioritization. Details in the new version should be verified in the text of the standard.
What is WCAG-EM?
A W3C method for evaluating whole sites against WCAG: it covers defining scope, exploring the site, sample selection, evaluation, and reporting.
Sources
- ETSI EN 301 549 V4.1.1 (2026-09)
- CAN/ASC EN 301 549:2024, identical adoption of V3.2.1 in HTML
- To be added by editorial: W3C WCAG-EM