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.

Then require evidence, not just a 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.

Acceptance criteria should be written as release gates. 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.

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.

The safest procurement language avoids 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.