- Primary source for the Article 15 presumption boundary and Article 14 fundamental-alteration or disproportionate-burden assessment.
"in so far as those standards or parts thereof cover those requirements"
WCAG test results are useful procurement evidence, but for EU Accessibility Act work they should be mapped through EN 301 549, Annex I requirements, and the exact product or service being accepted.
This page helps define acceptance criteria, collect supplier evidence, and avoid unsupported claims that a WCAG report alone proves EAA conformity.
Structured answer sets in this page tree.
Cited legal and guidance references.
For EU Accessibility Act procurement, evidence should answer a narrow question: does the supplier's tested ICT, version, content type, and user journey satisfy the accessibility requirements that apply to this purchase? A useful acceptance pack ties WCAG findings to clauses, the EAA Annex I requirement being supported, any product or service conformity evidence, and explicit limits on what has not been proven. A is a separate legal conclusion that depends on the exact Official Journal citation and the EAA requirements it covers.
is a practical bridge between testing and European ICT accessibility procurement. V3.2.1 applies to ICT products and services, including web pages, mobile applications, desktop software, hardware, and combinations of hardware and software. ETSI identifies that edition as supporting the Web Accessibility Directive. ETSI listed V4.1.0, dated June 2026, as on approval on 25 July 2026. The earlier November 2025 public-enquiry draft shows the proposed EAA mappings, but neither a draft nor an approval-stage text is a final standard or an Official Journal reference.
A report can support accessibility acceptance for web content, documents, and software interfaces, but it does not by itself prove EU Accessibility Act conformity. Record which clauses were tested, which clauses were not applicable, which non-WCAG requirements also matter, and whether an EAA harmonised-standard reference published in the Official Journal covers the requirement at issue.
Check whether supplier WCAG reports, EN 301 549 mappings, procurement acceptance criteria, and EAA conformity claims stay within what the evidence supports.
Ask cited EAA, EN 301 549, and procurement evidence questions before accepting supplier claims.
Review your acceptance criteria, standards mapping, supplier evidence, and residual-risk wording.
Procurement should be written as contract tests, not marketing promises. For each deliverable, name the exact service, user journey, platform, software build, document set, hardware model, and assistive technology environment covered by the evidence. Then state the clauses or EAA Annex I requirements the supplier must satisfy before payment, launch, or renewal.
For covered products and services, Article 24 treats the applicable Annex I requirements as mandatory accessibility requirements within the public procurement directives. That rule does not make every supplier statement sufficient and does not turn the buyer's contractual acceptance into a legal conformity decision. The buyer still needs testable criteria, corrective-action thresholds, retest rules, and a clear decision on whether an issue blocks acceptance, allows conditional acceptance, or is out of scope for the procured item.
Use a four-step acceptance decision: confirm the procured item and EAA or procurement scope; identify every applicable clause and Annex I requirement; test the delivered version and representative end-to-end journeys; then record accept, conditional accept, or reject with defects, compensating access, owner, deadline, and retest evidence. Contractual acceptance closes a procurement gate, not the supplier's continuing product or service duties.
Supplier evidence should be specific enough for a buyer, auditor, or authority to reproduce the conclusion. Ask for the test scope first: product or service name, version, build, modules, languages, markets, environments, content formats, assistive technologies, testing method, tester independence, known limitations, and remediation status.
For products, the EAA requires manufacturers to draw up technical documentation and an EU declaration of conformity when the applicable product procedure demonstrates compliance. For services, providers must prepare information explaining how services meet applicable accessibility requirements and keep that information while the service operates. Procurement files should preserve those product or service records separately from test reports.
Article 15 creates a only for products and services that conform with harmonised standards, or parts of them, whose references have been published in the Official Journal, and only so far as those standards cover the relevant accessibility requirements. The Commission's harmonised standards page also states that use of harmonised standards remains voluntary and that operators may choose another technical solution to demonstrate compliance.
An acceptance memo should say what is presumed, what is technical evidence, and what remains a legal or product decision. If has been used outside a cited EAA harmonised-standard reference, describe it as a technical benchmark or contractual requirement, not as an automatic presumption of EAA conformity.
"in so far as those standards or parts thereof cover those requirements"
"originally published in 2014 to support public procurement of accessible ICT"
"Key EU legislative instruments"
"The use of these standards remains voluntary."