Crafting an Accessible Kiosk RFP: Meeting EAA and EN 301 549 Standards

You’ve just been tasked with deploying several new self-service kiosks across hundreds of locations in the European Union. You’ve defined the tasks the kiosk needs to support and sketched out the requirements for the solution you want to implement. Now, it’s time to draft a Request for Proposal (RFP) to bring in vendors who can turn this vision into a reality.

With the European Accessibility Act (EAA) set to go into effect on June 28, 2025, kiosks installed in the EU after that date must meet EAA accessibility requirements. How can you ensure your kiosk meets EAA accessibility requirements while also providing a quality user experience for all users?

When preparing an RFP — or Request for Quote (RFQ) — for a kiosk project, it’s important to include specific accessibility requirements so that you communicate expectations to vendors. Establishing clear accessibility requirements in your RFP, along with your expectations of how vendors will be accountable for meeting accessibility requirements, creates a foundation for inclusive and high-quality kiosk solutions.

Why EAA Compliance Matters for Kiosks

The EAA defines specific accessibility requirements for new ATMs and self-service kiosks installed in the EU after June 28, 2025, and which provide consumer services like payment, ticketing, check-in, banking services, and access to passenger travel information.

The EAA’s requirements affect both the public and private sectors. EAA also requires kiosk providers to maintain documentation of their product’s conformance with requirements that can be made available to EU member state monitoring agencies on demand.

EAA sets general accessibility requirements plus specific requirements for self-service terminals and services. EAA doesn’t provide in-depth technical requirements; instead, kiosk providers can follow the companion standard EN 301 549, which provides more detailed technical accessibility requirements for websites, software, hardware, and digital documents. Although EN 301 549 is a voluntary standard, evidence of conformance with EN 301 549 is an excellent way to demonstrate a kiosk’s conformance with EAA.

Key Accessibility Requirements to Include in Your Kiosk RFP

The RFP is an opportunity to articulate your accessibility requirements clearly. At a high level, they can be expressed in three groups:

1. Hardware accessibility features: List hardware accessibility features needed to enable people with disabilities to operate the kiosk and receive output. This includes audio output support with volume control, a headphone jack to enable private listening of audio, tactilely discernible controls that can be used to operate the interface without excess strength or dexterity demands, and tactile labeling of functionality like printers and card readers.
2. User interface accessibility features: Request that the software user interface provided for the kiosk be designed with accessibility in mind. This includes ensuring that all content displayed on the screen can be accurately output in speech, that navigation through all content is efficient, that the visual screen design supports readability, and that time limits are managed carefully in an accessible way.
3. Evidence of conformance with EAA requirements: Request evidence of conformance with EAA’s accessibility requirements for self-service terminals. This should include information on conformance with EN 301 459’s requirements for hardware and software and details of how people with disabilities were included in the kiosk development and testing process.

For complex use cases, consider consulting with a kiosk accessibility expert to ensure the RFP covers all necessary accessibility aspects. Accessibility needs may vary depending on whether a kiosk is used for tasks like healthcare check-ins, bill payments, or self-service at quick-service restaurants (QSRs).

Baseline Accessibility Requirements for Kiosk RFPs

While a consultant can offer tailored guidance, here are some baseline requirements to include in your RFP:

Low Vision Support

Screen text should be presented in a large, easy-to-read font. When specifying the colors of text and other interface elements, avoid low-contrast color schemes.

Speech output

Speech output is essential to allow users to interact with the kiosk non-visually. This output must be available for all languages the kiosk supports and provide an equivalent experience for all visible content.

Speech should be tailored to support efficient nonvisual interaction — for example, JAWS for Kiosk is a screen reader application specifically adapted to support kiosk user experience. For convenience, the screen reader should auto-activate when headphones are plugged in and turn off when headphones are removed.

Visual Alternatives for Audio Content

All audio alerts and announcements must be paired with visual equivalents to ensure that deaf or hard-of-hearing users have equal access to information. Caption all multimedia content displayed on the screen.

Accessible Input Devices and Controls

Provide accessible input options for data entry and navigation. Options might include a high-contrast, large-print onscreen QWERTY keyboard for data input and a multi-directional tactile navigation device. Voice recognition can be offered as an input mechanism but should only ever supplement, not replace, tactile controls.

Tactile Labeling

Include tactile labels (such as Braille) to identify key input and output features, such as card readers or headphone jacks. Provide accessible instructions to help users activate accessibility features.

Vendor Accountability and Contractual Expectations?

Your RFP should state that the selected vendor will be required to enter into a contractual agreement that includes accessibility delivery obligations and accountability measures to help your efforts to comply with the European Accessibility Act (EAA).

Your contractual relationship with the selected vendor could include:

• Remediation obligations, where the vendor is required to implement a plan to address any accessibility issues that arise post-deployment.
• Financial or contractual consequences if agreed-upon accessibility requirements are not met.

Setting this expectation early in the RFP process helps ensure that vendors are prepared to take responsibility for accessibility delivery and are ready to partner with you in providing an accessible kiosk.

Setting the Foundation for an Accessible Kiosk Deployment

An RFP with clearly defined accessibility requirements not only sets your project up for success but helps to ensure that the kiosk solution you procure can be accessed and used by all users, regardless of disability.

By defining specific requirements and responsibilities at the RFP stage, you can help ensure that vendors approach the project with a comprehensive understanding of your accessibility needs — or collaborate with partners who do. This attention to detail in your RFP makes it easier to solicit vendor capability to deliver accessibility needs, compare vendor responses, and select the most capable vendor.

If you’re ready to set up a strong accessibility foundation for your kiosk deployment, TPGi will help you define, refine, and implement accessibility standards that support compliance and create an inclusive user experience. Contact us to start your journey toward accessible kiosk solutions.

Additional Resources

EAA Resource Center

TPGi’s European Accessibility Act (EAA) Resource Center features timely webinars, downloadable resources, and blog posts about the EAA and other accessibility laws impacting EU member states. Explore the resource center to get answers to your EAA questions.

Self-Service Kiosk Compliance Fact Sheet: European Accessibility Act

TPGi’s fact sheet is your quick-start guide to understanding and achieving compliance with the EAA. Download the Self-Service Kiosk Compliance Fact Sheet to learn more.

WCAG (Web Content Accessibility Guidelines)

Learn more about kiosk application guidelines in the article “Does WCAG Apply to Kiosks?” and directly on the WCAG website. These can be called out specifically or referenced generically in the RFP.