EU Accessibility Act EN 301 549 and WCAG mapping

Treat the three layers separately. The EAA is the legal source: Article 4 points covered products and services to the applicable Annex I accessibility requirements. Article 15 gives a presumption of conformity only for harmonised standards, or parts of them, whose references have been published in the Official Journal and only to the extent those standards cover the Directive requirements.

EN 301 549 is the European ICT accessibility standard. ETSI describes V3.2.1 as the latest published version on its EN 301 549 V3 page, with a planned V4.1.1 revision in support of Directive (EU) 2019/882. That version context matters: a mapping should name the EN 301 549 version used and should not claim EAA presumption of conformity beyond the cited harmonised standard or OJEU reference.

WCAG is narrower. EN 301 549 V3.2.1 says WCAG 2.1 Level AA conformance is equivalent to conforming with the standard's web clauses 9.1 to 9.4 and clause 9.6. EN 301 549 also contains requirements outside web content, including functional performance statements, closed functionality, biometrics, hardware, two-way voice communication, video, documentation, support services, relay services, and emergency service access.

WCAG test results are useful evidence, but their evidentiary boundary must be explicit. For a public website, account portal, checkout flow, web document, or software user interface, WCAG 2.1 results can support the corresponding EN 301 549 web, document, or software clauses. The evidence should identify the URL, screen, component, document, app version, assistive-technology assumptions, failed criteria, retest date, and remediation owner.

WCAG evidence does not, by itself, prove every EN 301 549 or EAA requirement. It does not prove whether a product is in EAA scope, whether a service provider has satisfied service information duties, whether a self-service terminal hardware interface is accessible, whether support services are accessible, whether an Article 14 exception is justified, or whether an OJEU-cited harmonised standard creates a presumption for the specific Annex I requirement.

Do not use WCAG 2.2 labels for an EN 301 549 V3.2.1 mapping unless a separate source and decision explain why that later W3C version is being used as additional internal evidence. The grounded EN 301 549 V3.2.1 material maps to WCAG 2.1, including the web clause equivalence statement.

Build the mapping as a requirements table, not as a pass/fail certificate. Each row should start with a covered product or service feature, then cite the EAA Annex I requirement being addressed, the EN 301 549 clause used as the technical control, and the evidence that proves the implementation for the tested release.

For web and app journeys, include WCAG 2.1 criteria where EN 301 549 points to them. For hardware, terminal, voice, video, closed-functionality, documentation, and support-service features, use the relevant EN 301 549 clauses and Annex C conformance checks instead of forcing every requirement into a WCAG row.

Add a version column. It should identify the EAA source, the EN 301 549 version, the WCAG version where used, the test tool or manual method, the product release, and whether the cited standard is being used as internal evidence or as part of an OJEU-based presumption analysis.

Review the mapping whenever the product feature set, supplier component, content template, assistive-technology assumption, or standard version changes. EAA Article 7 and Article 13 also require product and service conformity procedures to account for changes in harmonised standards or technical specifications used for the declaration.

Escalate rows that depend on Article 14. A fundamental-alteration or disproportionate-burden conclusion is not a WCAG failure note; it is a separate EAA assessment that must be documented, retained, and provided to authorities on request under the Directive's conditions.

Keep the final claim modest. A good page-level claim is 'this release has WCAG 2.1 and EN 301 549 evidence for the listed web journeys.' A broader EAA claim needs scope analysis, Annex I coverage, standards-version review, service and support evidence, product documentation, and exception records where relevant.