European Accessibility Act checklist for self-service kiosks

Establish the legal and service scope before specifying a kiosk

Begin with the service, not the enclosure. A payment terminal, ticketing machine, check-in terminal and information kiosk may look similar while carrying different obligations. Record what the user is doing, who provides the underlying service, where the terminal will be offered and whether the interaction completes a transaction. Ask legal or compliance owners to map that description against the applicable national law rather than relying on a supplier statement that a device is simply “EAA ready.”

Identify each economic-operator role as well. The organization placing a product on the market, the service provider, the software operator, the payment provider and the site operator may control different parts of the experience. A technically capable terminal cannot compensate for an inaccessible service flow, missing instructions or support process. Equally, an accessible application can fail when it is installed at an unsuitable height or behind an obstructed approach.

Treat this gate as a maintained decision record. The conclusion may differ by country or service even when the hardware is identical. Avoid turning a regulatory question into a one-time checkbox owned only by procurement.

Convert accessibility principles into a requirement matrix

Procurement language should describe an observable outcome and a method of verification. “The kiosk must be accessible” is not testable. “A user can complete the defined journey without vision, within the supported service boundary, using the supplied audio-access method” creates a result that can be demonstrated. Build requirements around the real journey: approach, orientation, start, identification, input, review, correction, payment, confirmation, receipt and assistance.

Add ownership and priority to every row. Some requirements sit in hardware, some in application code, some in content, and some in site operations. The matrix should expose gaps between those contracts. It should also separate mandatory scope decisions from broader inclusive-design improvements that the organization chooses to adopt across its estate.

Include information and documentation in the same matrix. Installation instructions, user guidance, support information and statements describing accessibility features need accessible formats and responsible owners. If a customer must scan a visual-only code or read a printed label to discover an accessible mode, the practical journey may already be blocked. Review every handoff from physical signage to on-screen help, mobile content or staff support. Specify language coverage and how translated guidance will be quality-assured.

Ask suppliers for evidence, limitations and ownership

Conformance claims need boundaries. Ask which product version, software release, peripheral set and configuration were assessed; which standard or test method was used; who performed the assessment; and what exceptions were found. A report for a screen or payment terminal does not prove that the assembled kiosk and complete service journey are accessible. Request evidence for the integrated configuration you intend to deploy.

Require a documented accessibility contact, defect-severity model, remediation process and update commitment. Clarify who pays for changes triggered by a browser update, payment application release, translated content or new peripheral. Include accessibility in change control so that a working journey cannot be broken by an ordinary campaign or software deployment.

• Accessibility conformance report with version and configuration scope
• Known exceptions, workarounds and planned remediation dates
• Test-device and assistive-technology combinations
• Hardware drawings, adjustable components and reach information
• Audio privacy, volume control and headphone behavior
• Release testing, regression testing and incident escalation
• Accessible documentation, training and customer support

Make evidence a scored procurement deliverable, not an optional appendix. Where a supplier cannot provide it, record the resulting test effort and risk in the commercial evaluation.

Test the physical installation and touch interaction together

A kiosk interface is experienced through a physical object. Screen angle, glare, reach, operating-force, privacy panels, approach space, plinth depth, card reader position, receipt collection and nearby furniture can change whether a person can use it. Include floor finish, queues, temporary displays and cleaning equipment in the site review; drawings often omit the objects that create real barriers.

For touch interfaces, examine target size, spacing, focus behavior, timeouts, gesture alternatives, zoom and contrast under the expected lighting. WCAG 2.2 is a useful reference for web-based kiosk interfaces, including minimum target size and avoiding drag-only interaction, but WCAG conformance alone does not establish conformance for an entire closed-function kiosk. Hardware and non-web software requirements still need their own assessment.

Test both seated and standing use without assuming a single “average” user. Confirm that the user can see prompts while operating every peripheral. Test with gloves where the environment requires them, with tremor and limited dexterity, and with realistic dwell time. Timeouts should warn users and offer a straightforward extension without removing completed work unexpectedly.

Design a complete non-visual and assisted journey

Adding a headphone socket does not create non-visual access. A user must be able to locate the start mechanism, understand privacy implications, control volume, move through choices, hear dynamic values, correct errors and receive confirmation. Audio must remain synchronized with the current state and must not expose sensitive information to people nearby. Test what happens when a headset is connected or removed halfway through a journey.

Instructions should not depend on color, shape or screen position alone. Provide meaningful labels, predictable navigation and clear status messages. Where a physical keypad or tactile control is used, verify its relationship with on-screen prompts. If staff assistance is part of the accessible service, define response time, privacy boundaries and staff training. Assistance is an operating commitment, not a sentence in a manual.

Consider users with hearing, speech, cognitive and language needs as well as vision and mobility needs. Use plain language, consistent terminology and recoverable steps. Avoid forcing voice interaction as the only alternative. Confirm that alerts have more than one sensory form and that essential instructions remain available long enough to understand.

Run representative user testing before rollout approval

Laboratory checks are necessary but not sufficient. Build a representative pilot with the intended enclosure, peripherals, application, connectivity, content and mounting arrangement. Recruit disabled participants whose access needs reflect the journey. Do not ask a project team to simulate disability and treat that as user research. Provide a safe mechanism for participants to stop, seek support and report barriers.

Create task-based scenarios rather than a tour of features. A participant should be able to find the terminal, begin unaided, complete the core task, recover from at least one error, request help and exit without leaving personal data exposed. Capture completion, abandonment, assistance, critical defects and qualitative friction. A fast completion by one user does not cancel a blocking barrier for another.

1. Freeze the configuration and record every version under test.
2. Run expert review and automated checks before participant sessions.
3. Test core, exception, timeout, offline and support journeys.
4. Prioritize defects by user impact, not cosmetic severity alone.
5. Retest fixes in the integrated system and obtain accountable sign-off.

Keep the resulting scripts as regression tests. They should run after major releases and on a sample of installed sites, not disappear when procurement closes.

Plan research accessibly as well. Recruitment material, consent, session instructions, venue access and incentives should not create barriers for the people whose experience is being evaluated. Tell participants which prototype functions are incomplete and avoid collecting unnecessary health information. Separate observations about the product from assumptions about an individual. After remediation, invite representative users to verify the changed journey; an internal screenshot review cannot confirm that a previously blocking issue has been resolved in the assembled kiosk.

Keep accessibility intact through operations and change

Accessibility can degrade after launch through content updates, peripheral substitutions, furniture changes, damaged audio components or staff turnover. Add accessible-journey checks to preventive maintenance and site audits. Monitor failures that may have unequal impact, such as a headphone socket that no longer detects a device or a touch calibration shift that reduces usable target area.

Publish an accessible way to report a problem without requiring the broken kiosk. Route incidents to owners who can distinguish application, hardware, content and site causes. Track remediation time for blocking accessibility defects separately from general support averages. When a temporary workaround is required, state how users will discover it and how long it will remain.

For multi-country estates, maintain a common baseline with controlled local additions. Revalidate translations, national support routes and any country- specific legal interpretation. The goal is not a certificate at launch; it is a service that remains usable throughout its operating life.

Official sources and further reading

Use current official material and the applicable national implementing law when making a compliance decision. Standards can support specification and testing, but they do not replace legal interpretation of scope.

• EUR-Lex: Directive (EU) 2019/882
• European Commission: The EU becomes more accessible for all
• AccessibleEU: EAA application overview
• W3C Recommendation: WCAG 2.2
• ETSI EN 301 549 V3.2.1