Procurement EvidenceEU Accessibility Act

EAA WCAG evidence and procurement acceptance

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.

Use this page to define acceptance criteria, collect supplier evidence, and avoid unsupported claims that a WCAG report alone proves EAA conformity.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

For EU Accessibility Act procurement, WCAG 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? The strongest acceptance pack ties WCAG findings to EN 301 549 clauses, the EAA Annex I requirement being supported, any product or service conformity evidence, and explicit limits on what has not been proven.

Section 1

Map WCAG evidence through EN 301 549 before accepting a supplier claim

EN 301 549 is the practical bridge between WCAG-style testing and European ICT accessibility procurement. ETSI describes the standard as applying to ICT products and services, including web pages, mobile applications, desktop software, hardware, and combinations of hardware and software. Its current V3.2.1 page says the standard supports the Web Accessibility Directive and is planned to be updated to support Directive (EU) 2019/882.

That boundary matters. A WCAG report can support accessibility acceptance for web content, documents, and software interfaces, but the procurement file should not state that WCAG alone proves EU Accessibility Act conformity. Record which EN 301 549 clauses were tested, which clauses were not applicable, which non-WCAG requirements also matter, and whether any harmonised standard reference published in the Official Journal covers the EAA requirement at issue.

Use WCAG evidence for the relevant EN 301 549 web, document, or software clauses, not as a substitute for the full EAA scope analysis.
Check self-scoping preconditions: if a feature, interface, document type, biometric flow, support service, or hardware control is present, the related EN 301 549 requirement may need separate evidence.
Separate three labels in the file: tested against WCAG, mapped to EN 301 549, and accepted for this procurement; do not collapse them into an unqualified EAA conformity statement.
Keep a standards register showing the EN 301 549 version used, the clauses tested, gaps deferred, and the reason any clause was treated as not applicable.

Sources for this answer

ETSI - EN 301 549 V3 for ICT accessibility

Supports the claim that EN 301 549 applies across ICT products and services and that V3.2.1 currently supports the Web Accessibility Directive while an EAA-supporting revision is planned.

Directive (EU) 2019/882

Primary legal source for EAA scope, Annex I accessibility requirements, economic operator duties, Article 14 exceptions, and Article 15 presumption of conformity.

European Commission - accessibility standardisation

Commission source explaining that EU accessibility legislation can refer to accessibility standards, including EN 301 549 for ICT accessibility.

Recommended next step

Review your accessibility evidence pack

Check whether supplier WCAG reports, EN 301 549 mappings, procurement acceptance criteria, and EAA conformity claims say exactly what the evidence supports.

Research workflow

Open Research Copilot

Ask cited EAA, EN 301 549, and procurement evidence questions before accepting supplier claims.

Explore next step

Talk to Sorena

Talk through implementation

Review your acceptance criteria, standards mapping, supplier evidence, and residual-risk wording.

Explore next step

Section 2

Procurement acceptance criteria that survive review

Acceptance criteria 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 EN 301 549 clauses or EAA Annex I requirements the supplier must satisfy before payment, launch, or renewal.

For public procurement, the EAA connects its Annex I accessibility requirements to mandatory accessibility requirements under the public procurement directives for covered products and services. That does not mean every supplier accessibility statement is sufficient. 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.

Require a clause-by-clause accessibility conformance matrix with pass, fail, not applicable, partially met, evidence link, tester, test date, version tested, and remediation owner.
Make acceptance conditional on representative journeys: account creation, authentication, search, purchase or transaction completion, help and support, error recovery, documents, and any mobile or self-service terminal interface included in the contract.
Define rejection rules for critical barriers such as keyboard traps, unlabeled controls in core flows, missing accessible names for transaction controls, inaccessible mandatory documents, or unresolved blockers in assistive technology testing.
Require retesting after material UI, content, platform, component, firmware, template, or supplier changes because Article 7(4) and product conformity duties expect continued conformity as design, characteristics, and standards change.

Sources for this answer

Directive (EU) 2019/882

Supports procurement relevance, Annex I requirements, product conformity documentation, and service-provider duties to keep conformity information while services operate.

ETSI - EN 301 549 V3 for ICT accessibility

Supports using EN 301 549 as a procurement-oriented ICT accessibility standard with self-scoping requirements and conformance evidence.

Section 3

Supplier evidence to request and keep

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 WCAG test reports.

Collect supplier EN 301 549 matrices, WCAG test reports, manual assistive technology notes, automated scan outputs, remediation logs, exception decisions, and final retest results.
For products, request the EU declaration of conformity, technical documentation references, CE-marking evidence where applicable, and any list of harmonised standards or technical specifications applied in full or in part.
For services, request the public accessibility information, operating procedures for continued conformity, incident and complaint handling route, and evidence that support, documents, and customer communications are accessible.
Treat supplier claims as time-bound: record the tested version and require notice when the supplier changes design, code, content templates, support tooling, hardware, or standards basis.

Sources for this answer

Directive (EU) 2019/882

Supports the product documentation, EU declaration of conformity, service information, and continued-conformity evidence expectations.

European Commission - harmonised standards

Supports requesting the exact standards basis and checking whether references have been published in the Official Journal before relying on presumption effects.

Section 4

Presumption of conformity and standards boundaries

Article 15 creates a presumption of conformity 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.

In practice, an acceptance memo should say exactly what is presumed, what is only evidence, and what remains a legal or product decision. If EN 301 549 has been used outside a cited EAA harmonised-standard reference, describe it as a strong technical benchmark or procurement requirement, not as an automatic presumption of EAA conformity.

Do not claim EAA conformity because a supplier passed WCAG tests unless the file also covers scope, applicable Annex I requirements, non-WCAG EN 301 549 requirements, and the relevant harmonised-standard status.
Do not claim a whole product or service is conformant when evidence covers only selected pages, documents, modules, countries, languages, journeys, or versions.
If Article 14 is invoked for fundamental alteration or disproportionate burden, keep the assessment and evidence separate from the WCAG results; it is not a WCAG pass.
If procurement accepts residual issues, record whether acceptance is conditional, time-limited, remediated before launch, or outside the procured scope.

Sources for this answer

Directive (EU) 2019/882

Primary source for the Article 15 presumption boundary and Article 14 fundamental-alteration or disproportionate-burden assessment.

European Commission - harmonised standards

Commission source explaining OJEU publication, voluntary use of harmonised standards, and alternative technical solutions.

Primary sources