EAA conformance documentation is structured around three core layers: a written declaration that the product or service meets EN 301 549 requirements, technical evidence backing that claim, and an accessibility statement published for end users. Each layer serves a different audience. The declaration is for market surveillance authorities. The technical file is for auditors and regulators reviewing the underlying work. The accessibility statement is for the public. Together, they form the paper trail that proves a product or service conforms to the European Accessibility Act.
| Component | What It Contains |
|---|---|
| Declaration of Conformity | Formal written statement that the product or service meets EAA requirements, signed by the responsible party. |
| Technical File | Evidence package: design specifications, audit reports against EN 301 549, evaluation methods, and remediation records. |
| Accessibility Statement | Public-facing document explaining how the product or service meets accessibility requirements and how users can report issues. |
| Retention Period | Five years from the date the product is placed on the market, or from when the service is last provided. |
The Declaration of Conformity
The declaration is the headline document. It states, in writing, that the product or service meets the accessibility requirements set out in the EAA and the harmonized standard EN 301 549. It is signed by the manufacturer, importer, distributor, or service provider responsible for placing the product on the market.
A declaration typically identifies the product or service by name and version, references the EAA and any applied standards, names the responsible party, and includes the signature and date. It is a short document. The weight sits in the technical file behind it.
What Goes Into the Technical File?
The technical file is where the actual evidence lives. If a market surveillance authority asks how you arrived at the conformance claim, this is what you hand over.
The file generally includes a product or service description, a list of the accessibility requirements that apply, the standards used to meet those requirements (almost always EN 301 549), and the evaluation methods applied. Audit reports, screen reader evaluations, and records of issues identified and resolved all sit inside the technical file.
For digital products and services, the audit report is the centerpiece. A manual accessibility audit against EN 301 549, which maps directly to WCAG 2.1 AA for web content, is the only way to determine conformance. Scans only flag approximately 25% of issues, so they cannot stand in for an audit inside the technical file.
The Accessibility Statement
The accessibility statement is the public face of the documentation. Unlike the declaration and technical file, it is written for end users, not regulators. It explains how the product or service meets accessibility requirements, what content or features may not be fully accessible, and how users can report issues or request information in an alternative format.
The statement should be easy to find. Most organizations link to it from the website footer. It is dated, kept current, and updated when significant changes are made to the product or service.
How the Three Layers Connect
The declaration claims conformance. The technical file proves it. The accessibility statement communicates it. Each document points back to the others, and each plays a separate role.
If the declaration is questioned, the technical file is reviewed. If a user encounters an issue, the accessibility statement gives them a path to report it. If the product or service changes materially, all three documents are revisited.
Supporting Evidence Auditors Look For
Beyond the audit report, the technical file benefits from secondary evidence. Records of remediation work, validation reports confirming issues were resolved, user evaluation results with assistive technology, and internal accessibility policies all strengthen the file.
Procurement documentation showing accessibility requirements were included in vendor contracts is also useful, particularly for services built on third-party components. The more the file shows accessibility was considered throughout development and operation, the more credible the conformance claim.
How Long Documentation Must Be Kept
Documentation must be retained for five years. For products, the clock starts the day the product is placed on the market. For services, it starts when the service is last provided.
This is a long window. Organizations should treat the technical file as a living archive, with each version of the product or service tied to the corresponding documentation set. When a major release ships, a new technical file is opened. The previous file is retained for the remainder of its five-year window.
Frequently Asked Questions
Do we need separate documentation for each product?
Yes. Each product placed on the market needs its own declaration of conformity and technical file. A service offering and a mobile app from the same company are documented separately, because they are evaluated against different parts of EN 301 549 and may have different responsible parties.
Can the accessibility statement replace the technical file?
No. The accessibility statement is a public summary. It does not contain the audit reports, evaluation records, or evidence that regulators review. The technical file is internal documentation that supports the public statement and the declaration.
What happens if documentation is incomplete when authorities request it?
Market surveillance authorities can require the organization to bring the product into conformance, restrict its availability, or remove it from the market. Incomplete documentation can trigger an investigation even when the product itself may be largely accessible.
Does an ACR satisfy EAA documentation requirements?
An Accessibility Conformance Report based on the EN 301 549 VPAT edition contributes directly to the technical file. It is not a replacement for the declaration of conformity or the accessibility statement, but it serves as strong evidence of how the product or service was evaluated against the harmonized standard.
EAA documentation is less about volume and more about clarity. A well-structured declaration, a complete technical file, and a current accessibility statement give regulators what they need and give users a way to engage. Accessible.org helps organizations build each layer with the evidence to back it up.
Contact Accessible.org for EAA conformance documentation support.
