Accessibility doesn’t end with your website or mobile app. Any self-service experience—kiosks, terminals, or point-of-sale (PoS) devices—must also meet accessibility requirements.

For most organizations, getting this right means working with a partner who has proven accessibility experience. And it starts earlier than many teams expect: accessibility requirements need to be clearly defined in procurement documents like an RFP or RFQ.

Start with accessibility in your RFP, not after

Before defining accessibility requirements in your RFP, you need to understand the regulations that apply to your organization. These vary based on organization type, kiosk purpose, and geographic location, but they directly shape what vendors must deliver.

In the United States:

In the European Union:

These requirements should be referenced or included in the RFP so respondents can address them directly. Even when an organization is not explicitly regulated, clearly defined, standards-based accessibility requirements are still essential. Without them, there’s a real risk of procuring kiosks that exclude people with disabilities from accessing services or completing transactions. At a minimum, an RFP should outline a comprehensive set of accessibility requirements and establish accountability up to and including penalties for failing to meet them.

Pros and cons of different approaches

There are multiple approaches to writing an RFP where the goal is to procure a kiosk solution that is accessible to users with disabilities. While a generic approach may work for some situations, more specificity will often discourage some vendors from submitting a response.

Generic accessible kiosk solution RFP text

There are two common methods for including accessibility requirements in a kiosk project RFP.

In the first method, the need for accessibility is stated but not clearly defined. For example, consider a government RFP with language of the following nature:

“Requestor will rely on the consultant as the expert on Point of Sale systems and the requirements placed on such systems by ADA, Section 508 and any other Federal statutes and guidelines. If the proposed system includes such functionality, please clearly detail the functionality, any additional equipment required to implement functionality and other systems the proposed system functionality integrate with – including specific manufacturer systems that are compliant with proposed system’s functionality. Also include in detail what Federal regulation or guideline mandates the additional functionality. Include section/subsection of the Federal regulation and/or guideline.”

This requirement pushes the responsibility for defining accessibility onto the provider, who must then interpret how to comply with the requirements of “ADA, Section 508 and any other Federal statutes and guidelines” that apply. While it’s a simple way to ask for an accessible solution, it doesn’t provide specific requirements. This ambiguity may lead to a wide range of proposed accessibility solutions in responses to the RFP, resulting in the following risks:

  • The variety of accessibility solutions makes it difficult for the requesting organization to objectively compare the merits of each solution to make a decision.
  • Responding organizations have varying levels of knowledge about accessibility, ranging from novice to expert. A general request can result in responses from sources that have limited kiosk-specific accessibility knowledge and who may provide commitments without the capability to deliver them.
  • Without clearly defined accessibility requirements included as part of the RFP, it may become difficult later in the process to hold the proposal respondent accountable should they deliver a kiosk with significant accessibility issues.

This general accessibility approach may be useful for a Request for Information (RFI) to gather initial responses and what accessibility features respondents suggest, but it’s not recommended for the RFP.  Instead, an RFP for a kiosk should include detailed information on accessibility requirements against which RFP respondents will be measured when making a vendor selection, and against which the selected vendor will be measured when delivering the kiosk solution.

Specific accessible kiosk RFP content

Providing clear, specific accessibility requirements helps vendors understand expectations and submit more relevant proposals, which makes it easier to compare responses. However, setting the bar unrealistically high can limit participation if vendors feel they can’t meet the requirements for technical or financial reasons. A well-crafted RFP strikes a balance: it defines meaningful accessibility requirements while allowing room to work with vendors to optimize outcomes. This approach helps attract stronger, more appropriate responses for the project.

Specific kiosk accessibility requirements

While certain requirements will vary depending on the organization and kiosk purpose, there are several accessibility requirements that can serve as a baseline, including support for a range of assistive technologies used by people with disabilities.

Low Vision Support

  • Low vision support (software such as ZoomText) includes screen magnification capability for people with low vision.
  • Avoid low contrast color schemes to ensure people with low vision can read text and distinguish content.
  • Avoid relying on color alone to present information to ensure people with color deficiency can access content.

Screen reader software

  • Speech output, provided through screen reader software such as JAWS or other similar alternatives, is required to support non-visual access. Screen reader software converts written content into spoken language, including static text, notifications and alerts, form input fields, buttons, and other user interface elements. Speech-based interaction is often accomplished through a tactile keypad incorporated into the kiosk; relying on touchscreens for input can create significant additional usability issues for speech output users.
  • It should be easy for users to access speech-based navigation without assistance. A common way to support this is to automatically start a screen reader once headphones are connected.
  • Canadian kiosk standards have requirements for distinct voices for information/instructions and for user interface content, and also the ability to select English or French speech when text-to-speech is selected. A screen reader solution should provide this option.
  • Select an operating system that has a screen reader that supports the features needed for an accessible kiosk deployment. JAWS for Kiosk, for instance, is available only for Windows and Android OS.

Accessible input device/controls

There are multiple options for supporting accessible navigation and data input.

  1. If a user will need to input alphanumeric information, consider a QWERTY keyboard. A large print etched metal keyboard with high color contrast ensures that people with low vision can operate it with ease.
  2. For kiosks that require little to no data input, a limited-key input device may be sufficient. A suitable input device should have multi-directional navigation keys and a select key. The device should have raised tactile identifiers to ensure easy identification and distinction of each key. As an ideal, physical input devices should be water-resistant for regular sanitizing purposes.

Other input options may be considered, but must not be the only input channel:

  • Voice recognition can also be used, but there must be an alternative for people with limited or no speech and people who are deaf or hard of hearing.
  • If biometric scanning is used for identification, a single method of biometric.

Accessible labeling

Kiosk accessibility standards require tactile labeling of hardware input and output elements, such as card readers and receipt dispensers in payment machines, as well as providing an accessible way to indicate how a user can activate accessibility features.  For example, this can mean:

  • Using Braille to identify specific input and output features, such as card and receipt slots, on payment kiosks.
  • Providing Braille or other tactile instructions on how to activate speech mode. In particular, there should be a tactile discernible indication of the location of a headphone jack, when plugging in headphones launches speech output.

Refreshable braille

A non-mandatory accessibility feature is a refreshable Braille display, which supports tactile access to content for deafblind users and blind users who use Braille. At the time of writing, the cost and robustness of refreshable Braille displays may limit their feasibility for kiosks, especially high-traffic devices, but future developments in display technology may change this situation.

Height, reach, and operability requirements

For operability by the widest range of users, including people using wheelchairs or scooters, kiosk hardware construction must meet height and reach requirements. These requirements ensure that users can reach the kiosk’s operable controls. Similarly, operable hardware controls must not require undue strength or dexterity. The ADA Accessibility Standards and European standard EN 301 549 both specify requirements for reach, height, and operability of physical controls, and these can be referenced or replicated in RFP requirements. A diagram can be a useful tool to include in an RFP, mirroring the requirements of standards and setting expectations for attributes such as screen height and placement of operable parts, such as scanners and keypads. It can help potential vendors assess their current products and the cost of providing a solution that meets the specified requirements.

Accessible software user interface

Accessibility requirements that apply to other digital resources, such as websites, also apply to kiosk software user interfaces. Requiring evidence of conformance standards such as the Web Content Accessibility Guidelines (WCAG) and EN 301 549 helps establish a baseline for accessible interface design. Organizations should also understand accessibility requirements specific to self-service software and user interfaces, including:

  • Structuring user interface content and interactive elements so screen reader users can understand the layout, hierarchy, and purpose of each screen.
  • Providing equivalent alternatives for multimedia, including alternative text for images, captions, and audio descriptions for video.
  • Ensuring logical focus management across all interface elements, so both static and interactive content can be accessed and understood.
  • Clearly labeling buttons, input fields, and other user interface components.
  • Providing clear, supportive error messages when input errors occur.
  • Supporting time limits accessibility, including clear indication and the ability to extend time limits through both visual and audio means.
  • Protecting user privacy across interaction modes. For example, ensuring that visually masked sensitive inputs are not announced via speech.
  • Ensuring onscreen keyboards are operable for all users when a physical QWERTY keyboard is not provided, including efficient use with speech output and physical input devices.

Consequences and penalties for not meeting RFP accessibility requirements

In addition to accessibility requirements, RFPs may outline the consequences or penalties if the delivered solution does not meet requirements. To emphasize the value of the partnership with a vendor, rather than a financial penalty, the RFP can set expectations that a vendor will update the product to meet accessibility requirements should the initial version of the delivered product fail to meet them, and to follow a risk mitigation plan to address the impact of barriers present in the solution.

Measuring kiosk accessibility success

If there are consequences for non-compliance with a delivered solution, it’s important to communicate to prospective vendors how meeting accessibility requirements will be measured and the evidence needed for measurement. One option for measurement is to require an Accessibility Conformance Report (ACR) for the solution, using the Voluntary Product Accessibility Template (VPAT). Another approach might be to request a report that contains appropriate accessibility information, such as:

  • Information on details and results of accessibility tests performed as part of product development
  • Details of features provided to help achieve accessibility and usability for people with disabilities
  • Information on core functions that cannot be accessed by specific disability groups.
  • Documentation on how to configure and install the device to support accessibility.
  • A roadmap for addressing known accessibility issues post-delivery

The RFP could also indicate expectations on the successful vendor to demonstrate how the product meets accessibility requirements, and where accessibility barriers may exist, for example, data from usability testing with people with disabilities. The ultimate evidence of success is that the product can be used independently by people with disabilities.

Additional kiosk recommendations

Certain regulations and standards may apply depending on the purpose of the kiosk, the location(s) where it will be used, and the status of the organization providing the kiosk. The following are common regulations and standards that can guide kiosk accessibility requirements:

Section 508 ICT accessibility standards

For kiosks provided by U.S. federal agencies and federally funded organizations, the accessibility requirements of Section 508 of the Rehabilitation Act apply, which are defined in the Revised Section 508 ICT Accessibility Standards. In particular, the Closed Functionality Hardware requirements in Chapter 4 directly apply to kiosks.

Section 504 requirements for healthcare providers

Healthcare providers that receive federal funding are subject to requirements of Section 504 of the Rehabilitation Act, including digital accessibility requirements introduced in 2024 by the Department of Health and Human Services (HHS). For kiosks, these requirements are broad rather than specific, but still emphasize the obligations of healthcare providers to ensure kiosks are usable by people with disabilities.

Air Carrier Access Act

The Air Carrier Access Act (ACAA) specifies accessibility requirements for airlines that must be followed when providing kiosks and other digital services relating to air travel. The ACAA requires that a minimum of one in four kiosks be accessible in any area where kiosks are deployed.

Voluntary Voting System Guidelines 2.0

Voting kiosks must be accessible to people with disabilities. The Voluntary Voting System Guidelines 2.0, published in 2021, integrates accessibility requirements through general requirements for voting kiosks, in particular in Principle 7 Marked, Verified, and Cast as Intended, and in Principle 8 Robust, Safe, Usable, and Accessible. This document provides important accessibility requirements for an RFP for a voting kiosk.

EAA and EN 301 549

The EAA places accessibility requirements on self-service terminals and payment devices used to deliver consumer services in the European Union. It establishes a broad set of accessibility requirements across covered products and services, including specific requirements for self-service terminals. EAA came into force on June 28, 2025, meaning any kiosk deployed after that date must comply, while providers of existing kiosks have a transition period to bring them into conformity.

To support EAA, the voluntary standard EN 301 549 provides detailed requirements for software and hardware accessibility, including specific requirements for closed functionality systems like kiosks. Version 4 of EN 301 549 is due to be published in the first half of 2026 and will become a harmonized standard to support EAA. This means self-service devices conforming to EN 301 549 Version 4 will be presumed to be in conformity with EAA.

WCAG

As the global de facto standard for web accessibility, WCAG is directly referenced by several other standards that apply to kiosks, including the Section 508 ICT Accessibility Standards and EN 301 549. If an RFP does not already reference standards that incorporate WCAG, it may be worth doing so explicitly, though note that WCAG specifically applies to the software user interface and not to kiosk hardware.

In general, WCAG 2.1 Level AA is a minimum expected conformance level for accessible kiosk software user interfaces, and conformance with WCAG 2.2 Level AA, the current version of WCAG, is preferable.

Build accessibility into your kiosk RFP from the start

A well-written RFP sets the foundation for procuring accessible kiosks. Clearly defining accessibility requirements, along with measurable criteria, regulatory references, and enforcement mechanisms, leads to stronger vendor responses and better outcomes. Requiring demonstrated accessibility expertise, either in-house or through a qualified partner, can reduce costly retrofits and project delays.

At the same time, standards alone are not enough. Limiting requirements to standards conformance can result in kiosks that are technically compliant but still difficult or impossible for people with disabilities to use. This is especially true given the wide range of kiosk use cases, technologies, and environments: from hospital check-in to bill payment, point of sale, and Quick Serve Restaurant (QSR) experiences.

If you’re developing an RFP for accessible kiosks, consider working with an accessibility expert to ensure your requirements are translated into real-world accessibility.