Accessibility Requirements for Digital and Physical-System Procurement

Put accessibility before award, not after

Accessibility is most often lost at the requirements stage. A platform that is not compatible with screen readers, or unreachable for a person in a wheelchair, cannot easily be fixed after go-live: corrections tend to be slow, partial and expensive. This is why several legal regimes tie accessibility to buying. In the United States, federal information and communication technology must conform to the Revised Section 508 Standards; in the European Union, the European Accessibility Act and the Web Accessibility Directive push contracting authorities to factor accessibility into technical specifications, selection criteria and award criteria.

Procurement clauses work by shifting the burden of proof to the vendor. Instead of hoping a product happens to work with assistive technology, the buyer names an outcome, a standard and a conformance level, then verifies them through evidence and testing. The trade-off is real: demanding documentation and demonstrations can raise the cost of bids and slow the process, so requirements should be scoped to what each purchase actually needs rather than pasted everywhere as boilerplate.

• Inaccessible functions are rarely fixable after delivery.
• Conformance as a contract term puts responsibility on the vendor.
• Over-requiring raises bid cost — calibrate scope to the purchase.

Choose the right standard for each layer

Digital interfaces are usually specified against the Web Content Accessibility Guidelines; in practice buyers ask for WCAG 2.1 or WCAG 2.2 at Level AA, and many jurisdictions are moving from 2.1 to 2.2. For information and communication technology more broadly — hardware, kiosks, operating systems, documents — Europe uses EN 301 549 and the United States uses Section 508. The two are closely aligned, and EN 301 549 has been adopted outside Europe, for example in Australia as AS EN 301 549.

Physical and built elements follow different references: in the United States the 2010 ADA Standards for Accessible Design set scoping and technical requirements for facilities, while Europe uses the EN 17210 functional requirements for the built environment. Self-service terminals such as ATMs and check-in kiosks sit on the boundary: their software is judged against web and ICT guidance, while their physical reach, tactile controls and audio feedback are judged as hardware. A useful practice is one short clause naming a functional performance requirement, followed by a technical clause naming the exact standard.

• Interfaces and content: WCAG 2.1 or 2.2, Level AA.
• ICT overall (software, hardware, documents): EN 301 549 (EU/Australia) or Revised Section 508 (US).
• Facilities, routes, signage: 2010 ADA Standards (US) or EN 17210 (EU).
• Kiosks and terminals: web standard for the interface plus ergonomic clauses for the enclosure.

Clauses that make conformance enforceable

The most useful contract terms treat accessibility as a deliverable with consequences. Standard drafting, illustrated by U.S. federal sample language, includes a conformance clause stating that ICT must fully meet the cited standard before delivery and final acceptance; an evidence clause requiring an Accessibility Conformance Report based on a current template; an acceptance clause that conditions final payment on a working demonstration; and a non-compliance clause obliging the vendor to repair or replace failing items at no cost within a stated period.

Equally important are clauses that protect conformance over time. Installation and configuration services must not be performed in a way that reduces conformance; maintenance, upgrades, substitutions and replacements must not lower the conformance level present at award; hosting services must not degrade the accessibility of hosted content, and the buyer keeps the right to test hosted solutions during the contract. Personnel supplying development, authoring, testing or accessibility services should be required to hold the needed knowledge and to provide documentation on request.

• Conformance before delivery and before final acceptance.
• Conformance report on a current template.
• Acceptance only after a working demonstration.
• Repair or replacement of non-compliant items at no cost within a stated period.

Physical systems: hardware and placement clauses

Physical procurement needs clauses about the device itself and about its context. Operable parts should sit within reach ranges, work with one hand and without fine motor control or tight grasping; controls should provide tactile and, where relevant, audio feedback; and any closed functionality that does not rely on a general-purpose device must still be operable without vision or hearing where the standard demands it.

For self-service and kiosk-type systems, require software conformance for the user interface plus ergonomic clauses for touch height, keypad and slot access. If the unit is placed in a building, add a clause tying delivery to the environment: an accessible route to the unit, clear floor space, and installation that preserves any accessible path of travel around it. Principles behind the ADA treat the path of travel, restrooms, signage and door width as scoping obligations triggered by construction or alteration — a reminder that the physical site, not only the product, may be part of the purchase.

Evidence in stages, verification at acceptance

A conformance claim is only as good as the evidence behind it. A staged approach keeps the burden proportionate: in round one, vendors provide a written statement of full, partial or no conformance; in round two, a completed conformance declaration identifying the test methods used and the conformance level; in round three, shortlisted vendors demonstrate the product live on the assistive technologies and accessibility features found in mainstream operating systems.

Before acceptance, require test results based on recognized methods, documentation of accessibility features and of any core functions that cannot be accessed, configuration and installation notes, and, for authoring tools, evidence that they can produce accessible output. Keep the right to run independent testing. Where a product is developed, configured or updated for the buyer, ask for a fresh conformance report with each change. Because even large vendors admit their products are not fully accessible and accessibility shifts between versions, treat a claim as a starting point rather than a conclusion.

Limitations, deadlines and jurisdiction

Requirements are not static, and compliance dates shift. Verify the current deadline for your jurisdiction before drafting. For example, the U.S. Department of Justice issued an interim final rule in April 2026 extending the Title II web and mobile compliance date to April 26, 2027 for public entities with a population of 50,000 or more and to April 26, 2028 for smaller entities and special districts. EN 301 549 is periodically revised, and guidance such as CEN-CENELEC-ETSI TR 101551:2026 now helps European buyers map technical specifications to the European Accessibility Act and the Web Accessibility Directive.

This article is general information, not legal advice: the standard that binds you depends on your country, the buying body and the product. Allow for legitimate exceptions (for example, genuinely archived content under some rules), but remember that an exception for a file does not remove the obligation to provide the information in an accessible format when it is requested. Budget realistically — accessibility evidence costs the vendor money — and ask that this cost be broken out in proposals rather than hidden.