Search every question across sub-FAQs

Start with the legal posture of the thing being documented. A product statement should not replace the EU declaration of conformity: manufacturers must draw up technical documentation, carry out the Annex IV conformity assessment procedure, draw up an EU declaration of conformity when compliance is demonstrated, and keep the technical documentation and declaration for five years after placing the product on the market.

A service statement should be framed differently. Service providers must prepare the service information described in Annex V, explain how the service meets the applicable accessibility requirements, make that information publicly available in written and oral format, including in an accessible manner, and keep it for as long as the service is in operation.

For either type, keep the public wording narrower than the evidence allows. Say exactly which product model, software version, service journey, website, mobile app, document set, support channel, or terminal is covered; which requirements were assessed; which standard or technical specification was applied in full or in part; what evidence supports the claim; and what remains out of scope or unresolved. The Directive applies through Member State transposition measures, so the record should also identify the country or countries where the product is placed or the service is provided and any national language or filing rule.

Use EN 301 549 and WCAG as scoped evidence, not as a blanket EAA certificate. The EAA creates a presumption of conformity for products and services that conform to harmonised standards or parts whose references have been published in the Official Journal of the European Union, or to technical specifications or parts established by a Commission implementing act under Article 15, and only so far as those standards, technical specifications, or parts cover the relevant EAA requirements.

EN 301 549 is broader than WCAG because it covers ICT products and services, including web content, non-web documents, software, hardware-related features, support services, and other ICT functions. Version 3.2.1 is referenced for the Web Accessibility Directive, but that status must not be carried over to EAA Article 15. ETSI published the final draft of EN 301 549 V4.1.0 in June 2026 with EAA relationship tables, but final-draft status does not by itself create an OJEU citation. WCAG evidence is useful for web content and related software/document requirements, but it does not by itself prove that a payment terminal, e-reader, banking workflow, e-commerce service, support process, or product documentation satisfies every EAA requirement.

Name the exact EN 301 549 version, clauses or test basis used, the WCAG level or success criteria where relevant, the parts not assessed, and any EAA requirements handled outside the web or software test.

The evidence pack should let a market-surveillance authority, service compliance reviewer, customer, procurement team, or support lead understand what was assessed and why the claim is limited the way it is. Keep public wording, technical files and service operating records aligned so the statement does not promise more than the underlying evidence shows.

For products, Annex IV requires technical documentation that makes it possible to assess conformity with the relevant accessibility requirements and, where Article 14 is relied on, to show why the requirement would cause a fundamental alteration or disproportionate burden. For services, Annex V information may rely on harmonised standards or technical specifications in full or in part.

Most poor EAA conformance statements fail because they are too broad. They describe an accessibility ambition instead of a tested product or service boundary, or they reuse a WCAG accessibility-statement template for EAA product and service obligations that need different records.

Write the narrowest truthful statement, keep the evidence matrix behind it, and update it when the product, service, standard, supplier, accessibility requirement, or known issue changes.

Directive (EU) 2019/882 defines e-commerce services as services provided at a distance, through websites or mobile device-based services, by electronic means and at the individual request of a consumer, with a view to concluding a consumer contract.

For checkout testing, that means the relevant scope is the consumer journey used to buy the product or service online. The review should not stop at a home page or product page audit if the consumer still needs to sign in, choose delivery, accept terms, authenticate, pay, or receive confirmation.

Use the EAA service requirements as the control map. Annex I requires service information to be provided through accessible channels, websites and mobile services to be perceivable, operable, understandable, and robust, and available support services to provide accessibility and assistive-technology compatibility information in accessible communication modes.

For a checkout, the practical evidence should show that the user can understand the offer, move through each step, enter and review data, recover from mistakes, authenticate where required, complete payment, and receive confirmation without losing accessibility support.

Service providers must prepare information explaining how covered services meet applicable accessibility requirements, make that information publicly available in written and oral format including accessible formats, and keep it for as long as the service is in operation.

The checkout evidence pack should therefore connect public service information with release evidence. It should be clear which checkout was tested, which EAA requirements were mapped, what standards or test methods were used, what defects remain, and how changes in the service or applicable standards will be reviewed.

The main risk is producing a generic accessibility statement that does not prove the checkout can actually be completed. Evidence is stronger when it follows the money path and the account path from start to finish.

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 published the final draft of EN 301 549 V4.1.0 in June 2026 with EAA relationship tables, but a final draft 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.

For products, prepare the file a market surveillance authority would need to evaluate the product against the EAA: product identification, role in the supply chain, applicable accessibility requirements, conformity assessment, EU declaration of conformity where relevant, CE-marking evidence where relevant, technical documentation, and any Article 14 assessment relied on.

For services, prepare the information required to assess service compliance: the covered service, the accessibility requirements applied, the information made available to users about how the service meets those requirements, complaint or report handling, corrective action status, and the authority contact owner. Record the service compliance authority named in the national implementing law rather than assuming the product authority handles both tracks.

The response should show the authority how the conclusion was reached. For products, keep the technical documentation complete enough to identify the product, the applied requirements, the conformity assessment route, the standards or technical specifications used, and the test or design evidence supporting the declaration.

For services, keep the current service information in an accessible format or equivalent document. The record should explain how the service meets the applicable requirements and how users, complaints, incidents, or authority findings lead to corrective action.