Accessibility for Self-Service Terminals and Apps Under the EAA: The Hardware-Plus-Software Scope

Most accessibility programmes I am asked to review are scoped as though the European Accessibility Act were a website problem. It is not. It reaches physical hardware in your branches, stations and forecourts, and that is the part the web-and-app teams have quietly left out.

The European Accessibility Act — Directive (EU) 2019/882 — has applied since 28 June 2025. The instinct in most firms was to point it at the digital front end: run WCAG against the public website, audit the mobile app, sign it off. That work matters, but it covers perhaps half of what the Act reaches. The Directive has a deliberate hardware-plus-software scope. It lands on the machines a customer touches as much as the screens they scroll, and a remediation programme that stops at the browser has a gap that a market-surveillance authority can walk straight into.

What the Act actually reaches

The EAA regulates a defined list of products and a defined list of services. That distinction is the one most firms miss, because their accessibility spend has all gone to the service side. On the product side the Act names, among others, self-service terminals — specifically payment terminals and certain terminals such as ATMs, ticketing machines, check-in machines and interactive self-service information terminals — together with consumer computing hardware and operating systems, smartphones and other consumer terminal equipment used for electronic communications, television equipment for digital services, and e-readers.

On the service side it covers electronic communications, elements of air, bus, rail and waterborne passenger transport, consumer banking services, e-books and their dedicated software, and e-commerce. If you sell to consumers online, or run a bank, a transport operator or a retail estate with unattended machines, you almost certainly have both a product obligation and a service obligation, and they are governed by different requirements. The general shape of why your digital products now have to be accessible is the easy half to grasp. The terminals are the half that gets deferred.

The endpoints that get missed

When I ask a firm to produce its in-scope inventory, the website and the app are always on it. What is routinely absent is the physical estate that meets a customer without a member of staff in between. In a bank that is the ATM fleet and the in-branch service kiosks. In a retailer it is the self-checkout and the card payment terminal. In transport it is the ticket vending machine on the platform and the check-in kiosk at the airport. In hospitality and parking it is the unattended payment column. Every one of those is a self-service terminal or a payment terminal in the Act’s sense, and every one carries its own accessibility obligation independent of anything on your website.

The reason they slip is organisational, not legal. Websites and apps sit with a digital team that already owns accessibility as a discipline. Terminals sit with facilities, retail operations, or a hardware vendor on a managed-service contract — teams that have never been handed WCAG and do not think of themselves as being in scope of an accessibility law. So the machines fall between two owners, and nobody inventories them until a complaint or an audit forces the question.

Different device, different requirement

The Act sets functional accessibility requirements in its annexes rather than a single pass mark, and the practical requirement genuinely differs by device type. The harmonised standard EN 301 549 is the reference most firms will build against, because conformity with a harmonised standard gives a presumption of conformity with the Directive. But EN 301 549 is not a web standard with a hardware appendix; it addresses ICT across web, non-web software, and physical products, and the terminal clauses ask for things a website audit never touches.

A self-service terminal cannot rely on sight and touch alone. That means providing a non-visual mode of operation — text-to-speech output through a standard headphone socket for a customer who cannot read the screen. It means tactile identification of keys, adequate contrast, adjustable timings for people who need longer, and an operable reach and interface for a wheelchair user. It means not using flashing that could trigger a seizure. None of that is satisfied by making the on-screen software accessible; it is a property of the enclosure, the hardware and the firmware, and it is frequently fixed by the machine’s manufacturer, not by you. That is why the terminal question is really a procurement and vendor-management question. A card payment terminal is a narrower case — often no screen of consequence — but it still has to be operable by touch and by feel, and PIN entry has to work for someone who cannot see the pad.

The web and app front ends are the part your existing programme already knows how to handle, and the discipline of turning WCAG 2.1 AA into a build gate rather than a year-end audit is the right pattern for them. It is simply not the whole estate.

The dates that lull people

The Act’s transitional measures are widely misread as a general reprieve. They are narrower than that. Service providers may continue to use products already lawfully in use to deliver a service until 28 June 2030, and service contracts agreed before 28 June 2025 may run to their expiry for no more than five years from that date. Self-service terminals lawfully in use before 28 June 2025 get the longest runway: they may keep operating until the end of their economically useful life, but no longer than 20 years after entry into use.

Read that carefully before you rely on it. The 20-year allowance applies to terminals already in the field, not to what you buy next. Any terminal you procure and deploy now has to be compliant now. The transition buys time to refresh an ageing ATM fleet on its natural replacement cycle; it does not license you to install a fresh batch of inaccessible machines and count two decades from today. Treated as a reason to defer procurement changes, it becomes a trap.

Building the inventory

The work that actually closes the gap is unglamorous: a single register of every consumer-facing endpoint, physical and digital, with an owner, an in-scope flag, the applicable requirement, the current conformance position, and the evidence behind it. The digital rows you can largely self-assess. The terminal rows you mostly cannot — you have to go to the manufacturer for an accessibility statement and, where it exists, the conformance documentation for that model. Some hardware carries a CE-related accessibility declaration you can build on; the interaction with product-marking regimes is the same territory as the Cyber Resilience Act’s obligations on anyone who ships product, and the two increasingly need reading together for connected terminals.

Microenterprises providing services — fewer than ten people and turnover or balance sheet at or below two million euro — are exempt on the service side, though the position on products is tighter, so do not assume the exemption clears a small firm that also places terminals on the market. For everyone else, the evidence a surveillance authority will ask for is documentary: what is in scope, against what requirement, and how you know it conforms. That is precisely what an accessibility conformance report has to be able to defend, terminal by terminal as much as page by page.

The firms that will be caught out are not the ones who ignored the EAA. They are the ones who did the website, believed they were done, and never wrote the ATM, the ticket machine and the payment terminal onto the list.