EU Accessibility Act Procurement Language and Acceptance Criteria
Use procurement language to require evidence for the exact covered product or service being bought, not a broad accessibility promise.
This guide translates EAA scope, Annex I outcomes, ICT evidence, product and service records, and exception handling into buyer-side clauses and acceptance checks.
Procurement teams should turn applicable EAA accessibility requirements into evidence-backed contract terms and . The EAA regulates covered economic operators; it does not prescribe the sample buyer wording on this page. Identify the covered product or service, require supplier records mapped to the applicable Annex I requirements, and avoid calling a delivery EAA-compliant unless the evidence supports that exact scope.
1
Section 1
Buyer clause structure
Start the clause with scope. Name the product or service, the EU market use case, the supplier role, the buyer-facing journey, and whether the item is one of the EAA product or service categories. Covered examples include computers and operating systems, payment terminals, ATMs, ticketing and check-in machines, e-readers, electronic communications, consumer banking, e-commerce, transport information, and e-books.
Require evidence alongside any warranty. The supplier should provide an accessibility requirement matrix, applicable standards or technical specifications, test results, unresolved issues, and any exception analysis. The buyer should reserve acceptance until the evidence matches the version, configuration, language, market, hardware, software, content, and service flow being delivered.
Public procurement has a separate legal layer. Article 24 of the EAA says its Annex I requirements constitute mandatory accessibility requirements for the covered products and services within Article 42(1) of Directive 2014/24/EU and Article 60(1) of Directive 2014/25/EU. Article 42 of Directive 2014/24/EU also requires technical specifications for procurement intended for use by natural persons to take accessibility or design-for-all criteria into account, except in duly justified cases, and to refer to mandatory EU accessibility requirements where they exist. Contracting authorities must apply national procurement law and equivalent-proof rules where required; private buyers can use the same evidence model without presenting it as a public-procurement duty.
Illustrative contract wording to adapt with procurement counsel: "For [delivery, version, configuration, markets and journeys], the supplier shall provide by [date] a matrix of the applicable Annex I requirements and agreed clauses, with test evidence and unresolved defects. Acceptance by [buyer role] requires [agreed defect threshold] and completion of the agreed retests. The supplier shall identify each position with its supporting assessment and notify [buyer contact] of changes affecting the evidence. Contractual acceptance does not release either party from applicable legal duties."
Require the supplier to identify the applicable EAA product or service category and the Annex I requirements it mapped.
Require a product evidence pack when hardware, firmware, software, or a self-service terminal is delivered, including technical documentation, EU declaration of conformity where applicable, applied standards, test evidence, and version identifiers.
Require a service evidence pack when a service is delivered, including accessible service information, design and operation descriptions, how relevant Annex I requirements are met, and operational change controls.
State that evidence is accepted only for the ICT requirements and versions it actually covers; it is not a blanket EAA conformity statement.
Require disclosure of any fundamental-alteration or disproportionate-burden position, including the requirement affected, rationale, evidence, authority notification where required, and review trigger.
Supports buyer clauses that distinguish covered products and services, Annex I requirements, product technical documentation, service accessibility information, Article 14 exception evidence, and the Article 24 treatment of Annex I as mandatory accessibility requirements in covered public procurement.
Supports the separate public-procurement duty to address accessibility or design-for-all criteria in technical specifications, the link to mandatory EU accessibility requirements, and the need to allow equivalent evidence under the Directive's rules.
Recommended next step
Set accessibility acceptance criteria for the delivered version
Use the clause structure, supplier evidence list, and acceptance criteria on this page to prepare a procurement review that distinguishes product records, service records, ICT standards evidence, and Article 14 exceptions.
Write as release gates tied to the contract. A supplier assertion is not enough; the buyer needs repeatable checks that show which requirements were tested, which were not applicable, which failed, and which were remediated before acceptance. Contract acceptance records a buyer decision and does not replace the manufacturer's, importer's, distributor's, or service provider's duties under applicable law.
For ICT, use as a structured test and requirements map where it fits the supplied product or service. Keep its boundary visible: the standard covers ICT products and services and can be applied to software, web pages, mobile applications, desktop applications, hardware, and combinations of hardware and software, but the legal conclusion still depends on the EAA scope and evidence for every applicable requirement. Any presumption must be tied to an EAA OJEU-cited harmonised standard or a technical specification established by a Commission implementing act, and only to its covered requirements.
No acceptance unless the delivered version has a requirements matrix tying each applicable Annex I outcome to test evidence, design evidence, or a justified not-applicable decision.
No acceptance unless defects that block use without vision, with limited vision, without hearing, with limited hearing, without colour perception, with limited manual ability, or with cognitive limitations are triaged against the covered journey.
No acceptance of a generic VPAT, WCAG statement, or marketing accessibility page unless it is tied to the delivered version and explains the covered EAA requirements.
No acceptance of partial evidence unless the supplier identifies the clauses applied, the clauses not applied, and the alternative solution used for remaining EAA requirements.
No production rollout unless remediation owners, retest dates, workarounds, and consumer-facing accessibility information are recorded.
State the test environment and sample: product model, firmware and software build, locale, browser or platform where relevant, assistive technologies, user settings, pages or journeys, documents, terminals, and support channels. Acceptance applies only to that tested scope unless the contract defines a supported equivalence method.
Supports using EN 301 549 as an ICT accessibility requirements and test-evidence map while limiting it to the products, services, and clauses it actually covers.
Supports the distinction between voluntary standards, mandatory legal requirements, and the need to check whether a standard reference is published for the relevant legal requirement.
3
Section 3
Supplier evidence to request
Ask for different evidence depending on whether the supplier provides a product, a service, or both. The EAA product route expects technical documentation that can assess conformity against the relevant accessibility requirements. The service route expects information explaining how the service meets those requirements in general terms and conditions or an equivalent document.
Make evidence freshness explicit. Product design changes, characteristics changes, harmonised-standard changes, service changes, and changes to technical specifications can affect whether earlier evidence still supports the procurement decision.
Product evidence: product description, model and version, applied harmonised standards or technical specifications, test reports, design and operation evidence, EU declaration of conformity where applicable, CE marking evidence where applicable, and any requirement exceptions.
Service evidence: accessible description of the service, explanations needed to understand operation, mapping to relevant Annex I service requirements, support and complaint handling evidence, and change-control records for service alterations.
Shared evidence: defect register, remediation commitments, accessibility statement or equivalent user information, third-party component list, assistive technology test notes, and supplier escalation contact.
Procurement record: buyer scope decision, supplier evidence index, accepted residual issues, rejection reasons, retest result, and the person authorized to accept the accessibility evidence.
Supports separate product and service evidence requests, including technical documentation for products and service information describing how accessibility requirements are met.
Supports using economic-operator role, conformity assessment, declaration, technical documentation, and market-surveillance concepts carefully in product procurement records.
4
Section 4
Article 14 exceptions in contracts
Do not let an exception become a vague exclusion. allows accessibility requirements to apply only to the extent that compliance would not fundamentally alter the basic nature of a product or service and would not impose a disproportionate burden on the economic operator concerned. That is narrower than saying accessibility is inconvenient, late, expensive, or outside the supplier roadmap.
Procurement language should require a written, requirement-by-requirement exception record before acceptance. The record should explain the affected requirement, evidence considered, alternatives assessed, why the remaining accessibility requirements still apply, and when the assessment must be renewed or reopened.
Require the supplier to document the assessment and retain relevant results for the required period unless the Directive gives a specific documentation exemption.
For service providers relying on disproportionate burden, require renewal when the service is altered, when requested by the relevant authority, and at least every five years.
Require the supplier to disclose external public or private funding provided to improve accessibility. (6) prevents an operator receiving that funding from relying on disproportionate burden; record the source and purpose before accepting the claim.
Require the supplier to make the product or service as accessible as possible for all requirements not covered by the justified exception.
Make exception acceptance conditional: the buyer may reject an exception that lacks evidence, covers more requirements than necessary, or conflicts with the delivered scope.
Supports Article 14 handling for fundamental alteration, disproportionate burden, documentation, renewal, funding limits, and authority information duties.
5
Section 5
Unsupported claims to avoid
Procurement language should avoid broad legal conclusions unless the buyer has the evidence to support them. Say what was checked, which requirements and standards were used, which version was tested, and what remains unresolved.
Avoid mixing EAA, WCAG, , public procurement, and national implementation rules into one unsupported label. They can be related, but each claim needs its own scope and source.
Avoid 'EAA compliant' unless the statement identifies the exact product or service, applicable requirements, evidence set, jurisdictional scope, and any exceptions.
Avoid ' compliant' unless the supplier names the version, clauses, product or service functions, and test method.
Avoid 'WCAG equals EAA' because web accessibility evidence may support part of an ICT assessment but does not answer every EAA product or service requirement.
Avoid accepting accessibility statements that omit hardware, firmware, documents, authentication, multimedia, support, ticketing, banking, checkout, or service-operation flows that are part of the purchased scope.
Avoid treating as a permanent waiver; require review when facts, services, standards, authorities, or supplier evidence change.
Supports careful use of accessibility standards across ICT, built environment, Design for All, EAA, Web Accessibility Directive, and public procurement contexts without collapsing them into one claim.
Supports the warning that EN 301 549 evidence must be scoped to ICT functions, clauses, versions, and the legal instrument it is being used to support.
Primary legal source for covered product and service requirements, Annex I accessibility outcomes, product technical documentation, service information, Article 14 exceptions, and presumption-of-conformity rules.
Supports buyer clauses that distinguish covered products and services, Annex I requirements, product technical documentation, service accessibility information, Article 14 exception evidence, and the Article 24 treatment of Annex I as mandatory accessibility requirements in covered public procurement.
Supports separate product and service evidence requests, including technical documentation for products and service information describing how accessibility requirements are met.
Show 1 more
Supports Article 14 handling for fundamental alteration, disproportionate burden, documentation, renewal, funding limits, and authority information duties.
Standards source for ICT accessibility requirement mapping and for limiting EN 301 549 claims to ICT products, services, functions, clauses, and versions.
Supports using EN 301 549 as an ICT accessibility requirements and test-evidence map while limiting it to the products, services, and clauses it actually covers.
Supports the warning that EN 301 549 evidence must be scoped to ICT functions, clauses, versions, and the legal instrument it is being used to support.
General EU product-law source for using manufacturer responsibility, conformity assessment, EU declaration, technical documentation, and market-surveillance concepts accurately.
Supports using economic-operator role, conformity assessment, declaration, technical documentation, and market-surveillance concepts carefully in product procurement records.
Primary EU source for public-sector technical specifications addressing accessibility, mandatory EU accessibility requirements, equal access, and equivalent evidence.
Supports the separate public-procurement duty to address accessibility or design-for-all criteria in technical specifications, the link to mandatory EU accessibility requirements, and the need to allow equivalent evidence under the Directive's rules.
Commission source for the role of accessibility standards in ICT, built environment, Design for All, public procurement, the EAA, and the Web Accessibility Directive.
Supports careful use of accessibility standards across ICT, built environment, Design for All, EAA, Web Accessibility Directive, and public procurement contexts without collapsing them into one claim.
Commission source for explaining that harmonised standards are voluntary tools and that legal compliance can also be demonstrated through other technical solutions.
Supports the distinction between voluntary standards, mandatory legal requirements, and the need to check whether a standard reference is published for the relevant legal requirement.