EU Accessibility Act Procurement Language and Acceptance Criteria

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 Article 14 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.

Write acceptance criteria 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 EN 301 549 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, OJEU-referenced harmonised standards or technical specifications, and the specific requirements covered.

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.

Do not let an exception become a vague exclusion. Article 14 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.

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, EN 301 549, public procurement, and national implementation rules into one unsupported label. They can be related, but each claim needs its own scope and source.