EU Accessibility Act FAQ EN 301 549 clause mapping

Use a two-layer map. The legal layer should identify the covered product or service, the economic operator role, the applicable EAA Annex I requirement, and any Article 14 fundamental-alteration or disproportionate-burden position. The technical layer should then show which EN 301 549 clauses apply to the ICT features being assessed and what test or review evidence supports each result.

EN 301 549 is self-scoping: many requirements begin with a precondition. If the precondition is true, assess the requirement and record the result; if it is false, record why the clause is not applicable. That is more useful than marking every clause pass or fail without explaining the product or service feature being assessed.

Keep WCAG in its correct boundary. EN 301 549 reflects WCAG 2.1 content and uses WCAG-based requirements especially for web pages, non-web documents, and software, but an EAA record still needs the Annex I requirement, product or service facts, and any product/service documentation required by the Directive.

A useful mapping table should let a reviewer see both the legal boundary and the technical evidence without reconstructing the project. It should not be a raw accessibility test export. It should explain why each clause was in scope, which EAA requirement it supports, what evidence was reviewed, and what remains unresolved.

Use separate columns for applicability, result, and presumption status. A passed EN 301 549 test is evidence. A presumption claim needs the additional Article 15 condition that the relevant harmonised standard or part has an OJEU reference and covers the specific EAA requirement.

WCAG evidence belongs inside the EN 301 549 mapping where EN 301 549 incorporates or aligns with WCAG requirements. For web pages, EN 301 549 treats WCAG 2.1 Level AA conformance as equivalent to conforming with clauses 9.1 to 9.4 and the clause 9.6 conformance requirements. EN 301 549 also has separate requirements for non-web documents and non-web software.

That means a WCAG audit should be normalized into EN 301 549 clauses instead of pasted into the EAA file as a standalone pass/fail list. The mapping should show which WCAG findings support which EN 301 549 rows, and which non-WCAG EN 301 549 clauses still need evidence.

State presumption narrowly. The EAA says products and services conforming with harmonised standards or parts of standards whose references are published in the Official Journal are presumed to conform only so far as those standards or parts cover the Directive's accessibility requirements. Technical specifications or parts established by a Commission implementing act under Article 15 carry the same presumption only for the requirements they cover.

Avoid broad wording such as 'EN 301 549 compliant equals EAA compliant'. EN 301 549 V3.2.1 is referenced for the Web Accessibility Directive. ETSI publishes V4.1.1 (2026-09) with an EAA-oriented mapping, but publication is not an OJEU citation. Record which standard version or part was applied, whether it has the required EAA legal status for the requirement at issue, which EAA requirement it covers, and what evidence demonstrates implementation.

Do not treat accessibility evidence as interchangeable across laws, standards, products, and versions. The EAA file should show the exact product or service, the exact Annex I requirement, the exact ICT feature, and the exact EN 301 549 clause or WCAG criterion being relied on.

Keep exceptions and unresolved scope questions visible. If a clause is not applicable, record the precondition that makes it not applicable. If an accessibility requirement is not fully met because of Article 14, keep that assessment separate from the EN 301 549 test result.