EU Accessibility Act Accessibility Conformance Statement Template

Start the statement with enough identification data for a customer, procurement reviewer, or authority to understand the assessed item without asking the project team for background. Separate products from services because the Directive uses different evidence structures: product technical documentation and EU declarations of conformity for products, and Annex V service information for services.

Use plain identification details such as the product model or service name, version, release, platform, geography, language coverage, consumer-facing channels, and the date the statement was last updated. State the EAA role, the applicable product or service category, and the assessment basis so the scope is clear without any draft placeholders.

For services, put the Annex V explanation in the general terms and conditions or an equivalent document. Make it publicly available in written and oral formats, including formats accessible to persons with disabilities, and keep it available for as long as the service operates.

Use wording that names the support channel and explains that users can request accessibility information and compatibility details in accessible modes of communication. Keep the description specific to the live support routes that are actually available.

The useful part of the statement is the mapping table. It should connect each applicable Annex I requirement to the tested feature, standard clause, evidence record, result, owner, and limitation. Avoid a single blanket sentence that says the whole product or service is compliant unless the evidence actually supports every applicable requirement.

Template table columns: requirement source; applicable product or service feature; standard or technical specification used; test method; result; evidence link or record ID; known limitation; owner; next review trigger.

If the statement covers a product, keep it aligned with the product technical documentation and EU declaration of conformity rather than treating it as a standalone promise. The statement can summarise the assessment, but the evidence file should show the general product description, applied standards or technical specifications, and any design, manufacture, operation, or Article 14 material needed to assess conformity.

Use a short factual summary that lists the standards or technical specifications used, whether they were applied in full or in part, and any solutions adopted where they were not applied. That gives readers a complete but concise view of the product evidence.

Do not use the statement to hide unresolved accessibility defects. Use limitation language only when the limitation is backed by evidence, a documented remediation plan, or a valid Article 14 assessment for fundamental alteration or disproportionate burden.

Use direct language that separates confirmed limitations from general scope. Make clear that a limitation is a specific, documented condition rather than a broad excuse for non-compliance.

The statement must point to reviewable records. Keep enough evidence to show what was assessed, who approved the conclusion, what standards or requirements were used, what defects remain, and how the statement will be updated when the service, product, requirements, or standards change. A statement date without version and scope data does not show that a later release was assessed.

Evidence register fields: record ID; product or service scope; Annex I requirement; standard clause or test criterion; test date; tester; result; defect or limitation; remediation owner; support workaround; approval; next review trigger.