If your bank or store runs ATMs, ticketing machines, check-in kiosks or unattended payment terminals, the European Accessibility Act now treats those machines as in scope alongside your website and app. Terminal accessibility is neither a software-only nor a hardware-only problem: it is the overlap of both, and that overlap is exactly where most compliance gaps hide.
This guide covers what the EAA actually requires for self-service terminals, which WCAG 2.2 and EN 301 549 features you need to build in, and how to stop your digital and physical accessibility teams from each assuming the other has it covered.
What the EAA covers, and why terminals are different
The EAA (Directive (EU) 2019/882) has applied since 28 June 2025. It covers e-commerce, banking, e-books and e-readers, electronic communications, audiovisual media access services, transport services and self-service terminals, which the directive names explicitly: ATMs, ticketing machines and check-in machines. The harmonised baseline is WCAG 2.2 Level A and AA delivered through the European standard EN 301 549. National laws implement it: Germany via the Barrierefreiheitsstärkungsgesetz (BFSG), France via the RGAA, Italy via the Legge Stanca with AgID guidelines.
Terminals differ from a website in one decisive way: they are closed functionality. A user cannot install a screen reader, plug in their own switch device, or pinch to zoom. Whatever accessibility the machine offers, it must offer itself. That is why EN 301 549 carries hardware and closed-functionality clauses (clauses 5 and 8) that go beyond what web-only WCAG asks for. You do not get to assume the user brings their own assistive technology.
A transitional rule is worth knowing: self-service terminals lawfully used to provide services before 28 June 2025 may keep running until the end of their economically useful life, capped at 20 years per machine. Anything you procure or substantially refresh from now on must conform. For the wider legal picture, see our European Accessibility Act overview and the WCAG criteria reference.
The accessibility features a compliant terminal needs
Think in two layers: the on-screen software (governed by WCAG 2.2 via EN 301 549) and the physical device plus closed-functionality behaviour (governed by EN 301 549 clauses 5 and 8). Both must pass.
Software layer (WCAG 2.2 A/AA applied to the kiosk UI)
- Text contrast of at least 4.5:1 for normal text and 3:1 for large text and user-interface components, sustained under the bright outdoor or harsh indoor lighting where many ATMs sit. Verify with the contrast checker.
- Visible, unobscured focus on every interactive element, covering 2.4.7 Focus Visible (AA) and the new 2.4.11 Focus Not Obscured (Minimum) (AA), so a user driving the UI with tactile keys always knows where they are.
- Target Size (Minimum) (2.5.8, AA): interactive targets of at least 24 by 24 CSS pixels, which on a fixed kiosk screen means physically generous, well-spaced buttons rather than crowded ones.
- No reliance on dragging movements (2.5.7, AA) or on entering the same information twice (3.3.7 Redundant Entry, A); offer Consistent Help (3.2.6, A) in the same place across every screen.
- Status Messages (4.1.3, AA) so progress, errors and confirmations are conveyed programmatically, not by a visual-only cue.
Hardware and closed-functionality layer (EN 301 549)
- An audio output mode with a standard 3.5 mm headphone jack and private listening, so a blind user can complete the whole transaction by ear without any displayed element being the only path.
- A tactile, discernible keypad with a raised marker on the 5 key and a defined layout, so the device is operable without vision and without a touchscreen-only flow.
- Reach, height and clearance ranges that work for wheelchair users, plus controls operable with one hand and without tight grasping, pinching or twisting.
- No function gated behind biometrics alone: if face or fingerprint is the only way in, you fail Accessible Authentication (Minimum) (3.3.8, AA) and exclude users who cannot use it. Provide an alternative.
- Enough time, with the ability to extend it, since users operating by audio or tactile input legitimately need longer than a sighted touchscreen user.
Where digital and physical accessibility overlap
The overlap is the part teams get wrong, because responsibility is split. The UI is built by a software vendor; the enclosure, keypad and audio jack are specified by a hardware OEM; the deployment, lighting and floor placement are owned by facilities or the branch team. Each part can be individually compliant while the combination fails.
Concrete overlap failures: a screen that passes contrast in the lab but washes out behind anti-glare glass in direct sun; a perfectly labelled UI whose audio mode was never wired to the headphone jack; a button that meets 24 by 24 px on screen but sits under a recessed bezel a wheelchair user cannot reach; a well-built flow with a short timeout an audio user cannot beat. None of these show up if software and hardware are tested separately.
The practical fix is to test the assembled terminal as one product with real assistive workflows: complete a withdrawal using only the audio mode and keypad, eyes closed; complete a ticket purchase from a seated position; run the UI through the same keyboard-driven path you would demand on the web, since tactile keys are effectively keyboard operation. Validate the on-screen software early with the same tooling you use for your site, including a free scan at AccessScan and a structured accessibility checklist before the build ever reaches the enclosure.
Does your web accessibility work carry over?
Partly, and it is a real head start. The same code patterns that pass an audit on your website (logical heading order, programmatic labels, visible focus, 4.5:1 contrast, status messages) drop directly into the kiosk software, so reusing accessible components saves time.
But a terminal is closed functionality: there is no assistive technology the user can install, no zoom gesture, no personal screen reader. You must build the equivalents into the device itself, the audio mode, tactile keypad, reach ranges and no-biometric-lockout that EN 301 549 clauses 5 and 8 require. Run the kiosk UI through the same web checks, then layer on the hardware and self-contained behaviour on top.
A practical compliance path for banks and retailers
- Inventory every terminal type and its in-service date, so you know which fall under the 20-year transitional window and which must conform now.
- Get accessibility into procurement: require WCAG 2.2 AA conformance for the UI and EN 301 549 clauses 5 and 8 conformance for the hardware in writing, backed by the vendor's own documentation, before you sign.
- Validate the software UI early and continuously with automated and manual checks; treat the kiosk build like a web app and lean on your existing audit practice.
- Test the assembled machine with disabled users and real audio, tactile and seated workflows, in the actual lighting and placement it will ship into.
- Publish an accessibility statement describing the terminal's features and a feedback route. Our accessibility statement generator and the EN 301 549 reference cover what to include.
The reassuring part: most of your web accessibility investment transfers. The new work is the closed-functionality layer, audio, tactile input, reach and no-biometric-lockout, and the discipline of testing the finished machine as a single product rather than two compliant halves.