Writing a Kiosk RFP: Recommended Accessibility Requirements

Posted on Tuesday, 11 August 2020 by Laura Miller

When creating a Request for Proposal (RFP) or Request for Quote (RFQ) for a kiosk project, it is important to include the accessibility requirements that respondents need to address in their submission. Government agencies, cities, municipalities, and other organizations receiving government funding have clear and defined accessibility standards they must meet. These standards should be referenced and/or included for respondents to view and address in their response. Even if the entity responsible for the RFP is not government-funded, it is still important to include clearly stated, standards-based accessibility requirements.

The exact legal requirements for an accessible kiosk for non-government entities are still being legislated, but the overall accessibility remains critical: the resulting kiosk could engender a lawsuit if people with disabilities are unable to use it. As such, the RFP should define a complete list of accessibility requirements for respondents and include penalties for not meeting those requirements.

Pros and cons of different approaches

There are multiple approaches to writing an RFP that result in kiosks that are accessible for users with disabilities. While a generic approach may work for some situations, more specificity will often discourage less qualified vendors from submitting a response.

Generic accessible kiosk solution RFP text

There are currently two different methods for including accessibility in a kiosk project RFP. In the first method, the need for accessibility is stated but not clearly defined. A recent government agency RFP included the following accessibility statement:

“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. All add-on software and hardware required to be compliant should be included in the quoted overall cost of the proposer’s system.”

This statement pushes the responsibility for defining accessibility onto the provider, who must 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 a compliant solution, it clearly fails to provide specific requirements. This ambiguity encourages a wide range of accessibility solutions in the proposals, resulting in the following risks:

  • The proposed accessibility solutions may vary widely, making it difficult for the requesting organization to make a decision since there is no way to know if they are comparing apples to apples when evaluating responses.
  • Responding organizations have varying levels of knowledge about accessibility, ranging from novice to expert. A general request can result in responses from sources that do not know anything about accessible kiosk forms or features. The specific accessibility recommendations may be vague, making them difficult to assess. For example, a generic request for 508 compliance may result in a response that simply states the kiosk “will be 508 compliant,” but with no corresponding specifics on how they will achieve this. Providing only generic direction on accessibility requirements from the requesting organization will ultimately make it harder to assess proposals.
  • 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 partially or totally inaccessible kiosk.

While this general accessibility approach may be useful for a Request for Information (RFI) to see who responds and what accessibility features respondents suggest, it is not recommended for the RFP.  Kiosk Project RFPs should include detailed information against which RFP respondents will be measured for the final deliverable. Below are a few options for specific language and requirements when writing an RFP/RFQ. If you are in need of guidance or assistance in writing the RFP, an accessibility consultant (such as The Paciello Group) can assist and will be able to provide specific criteria to which respondents can comply.

Specific accessible kiosk RFP content

The below accessibility requirement description is from a State of Maryland Kiosk RFP. As in the government RFP mentioned earlier, it includes generic reference to accessibility requirements, but the language provides a bit more specificity around prompts and accessibility for users who are blind or who have low vision.

“The bidder or offeror warrants that the information technology offered under this bid or proposal (1) provides equivalent access for effective use by both visual and nonvisual means consistent with the standards of Section 508 of the federal Rehabilitation Act of 1973.; (2) provides an individual with disabilities with nonvisual access in a way that is fully and equally accessible to and independently usable by the individual with disabilities so that the individual is able to acquire the same information, engage in the same interactions, and enjoy the same services as users without disabilities, with substantially equivalent ease of use; (3) will present information, including prompts used for interactive communications, in formats intended for both visual and nonvisual use; (4) if intended for use in a network, can be integrated into networks for obtaining, retrieving, and disseminating information used by individuals who are not blind or visually impaired; and (5) is available, whenever possible, without modification for compatibility with software and hardware for nonvisual access.”

The RFP language should include specific requirements that a respondent can use to determine pricing for their proposal. An example from a recent federal government RFI includes a diagram of a kiosk with measurements for an accessible deployment. A diagram can be a useful tool to set parameters for screen height and device placement and to illustrate where kiosk components should be arranged in order to provide an accessible solution.

Person in a wheelchair in front of a kiosk. Kiosk measurements provided for an accessible kiosk.When writing a kiosk RFP for an accessible kiosk, it may be useful to employ the assistance of a kiosk accessibility expert. Standards – as they are currently written – are insufficient and may yield an “accessible kiosk” (meaning it adheres to standards) that is not actually usable by people with disabilities. This is particularly critical given the wide range of kiosk use cases, technology, and components. Kiosks used for check-in at a hospital require different features than those built for bill payment, point of sale, Quick Serve Restaurant (QSR), or contact tracing.

RFP Text for Specific Kiosk Accessibility Requirements

While hiring a kiosk accessibility expert will help in determining criteria for an RFP, there are a few requirements that any organization can use as a starting point. Some suggested requirements include:

Low Vision Software

  • Low vision software (often screen enlargement/magnification software such as ZoomText or other similar software solutions) is required. This software solution will provide screen magnification for individuals with low vision and allow them to access the user interface without assistance.
  • Low vision software also includes features for color inversion. Color inversion is a required accessibility mode that allows low vision or color-blind users to switch color inversion on/off.
  • An alternative to low vision software may be speech output customized for this application. This is an option for solutions that are not dynamic or changing as it is difficult to maintain and needs to be customized and updated each time the interface is modified.

Screen Reading Software

  • Screen reading software such as JAWS or other similar alternative is required. Screen reading software will provide the end user with non-visual access support that enables the user to hear the screen’s content spoken aloud. It accomplishes this by way of a tactile input device incorporated into the kiosk.
  • The installed screen reader should auto start when headphones are connected. This is a required feature.

Accessible Application or Website

  • It is required that any application or GUI is appropriately coded so a screen reader user can interact with the respective content with ease.
  • Appropriate coding guidelines can be found via WCAG 2.1 AA (or AAA where feasible).
  • Any application or GUI should not utilize color alone to convey meaning or determine an action. This specification will prevent access issues for those with color blindness.

Visual Alternatives to Audio

Captioning or other visual alternatives for audio prompts are required. It is vital that all audio commands and prompts are conveyed via captioning so deaf and/or hard-of-hearing users will have full access to the kiosk. Multimedia content should also have captions.

Accessible Input Device/Controls

There are multiple options for accessible navigation and data input. If a user will need to input information, consider a QWERTY keyboard. For kiosks that require little to no data input, navigational devices may be sufficient. Such navigation/input devices’ options are described below and should be water-resistant for regular sanitizing purposes. Sanitizing instructions, such as those provided by Storm-Interface can help to determine if a device is suitable for public use.

  • Option 1) A large print etched metal keyboard with high color contrast so individuals with low vision can access it with ease.
  • Option 2) Tactile navigation device with multi-direction and “select” buttons. The device should have raised tactile identifiers for users who are blind and have low vision that they can identify by touch.
  • Option 3) Other input options such as voice recognition can also be used and requested, but for accessibility purposes should be included as a supplement, not a replacement, for a tactile navigation device that will be utilized by individuals who are deaf or unable to speak. This does not preclude the system from offering speech input as an option, but speech must not be the only means of input.

Braille Labeling

Include Braille labeling or embossing on key areas of the machine to support ease of use. For example, using Braille to identify specific kiosk features such as card and receipt slots on payment kiosks, or providing Braille instructions on how to activate accessibility features can assist a user who is blind in identifying the location and use of necessary kiosk components. Braille labeling to find the headphone jack is required and is vital for accessibility.

Refreshable Braille

A refreshable Braille display is not currently a common feature on accessible kiosks, but is recommended and provides certain benefits for users. A refreshable Braille display is particularly helpful when a kiosk requires sensitive data or extensive text entry, like with a financial or healthcare kiosk. This hardware will allow users who are deaf/blind to access important on-screen content via a refreshable Braille display device included on the kiosk. Note that this device may not be appropriate for kiosks with high usage or high instances of physical abuse.

ADA Height and Reach Requirements

The kiosk hardware construction must meet ADA Standards Section for height and forward reach.  These standards include 407.8.3 (Forward Reach), 407.8.3.1 (Unobstructed Forward Reach), 407.8.3.2 (Obstructed Forward Reach), and 407.8.3.2.1 (Operable Part Height for ICT with Obstructed Forward Reach).

Consequences and penalties for not meeting RFP accessibility requirements

In addition to accessibility requirements, RFPs should outline the consequences or penalties if the solution is not accessible.  An example of this would be:

“If the information technology procured under this solicitation does not meet the nonvisual access standards set forth in this RFP, the purchaser will notify the bidder or offeror in writing that the bidder or offeror, at its own expense, has 12 months after the date of the notification to modify the information technology in order to meet the nonvisual access standards.  If the bidder or offeror fails to modify the information technology to meet the nonvisual access standards within 12 months after the date of the notification, the bidder or offeror may be subject to a civil penalty of a fine not exceeding $5000 for a first offense, and a fine not exceeding $10,000 for a subsequent offense.”

The author of the RFP can adjust the penalty fines as needed.

Rather than a financial penalty, an alternative would be a compulsion to “make good” on accessibility features and update the product to meet the standards and requirements outlined should it fail to meet them the first time around.

For example:

“In the event of Non-Compliance: Before final acceptance of any ICT item, including updates and replacements, if the offeror claims its products or services satisfy the applicable Revised 508 Standards specified in the statement of work, and the contracting officer determines that any furnished ICT item is not in compliance with such requirements, the contracting officer will promptly inform the offeror in writing of the noncompliance. The offeror shall, at no cost to the agency, repair or replace the non-compliant products or services within the period specified by the contracting officer.”

In either case, to ensure the request for accessibility is taken seriously, consequences must be defined and should be significant enough so RFP respondents pay appropriate attention to the accessibility criteria.

Measuring kiosk accessibility success

If there are consequences for non-compliance, the definition for how success will be measured is important.  One option for measurement is to require an Accessibility Conformance Report (ACR) for the kiosk solution.  The ACR would be based on the Voluntary Product Accessibility Template (VPAT™).   An example of language for conformance is below:

“Before acceptance, the contractor shall provide an Accessibility Conformance Report (ACR) for each ICT item that is developed, updated, configured for the agency, and when product substitutions are offered. The ACR should be based on the latest version of the Voluntary Product Accessibility Template (VPAT™) provided by the Information Technology Industry Council (ITIC).

Before acceptance, when the contractor is required to perform testing to validate conformance to the agency’s accessibility requirements, the vendor shall provide a Supplemental Accessibility Report (SAR) that contains the following information:

Accessibility test results based on the required test methods.

Documentation of features provided to help achieve accessibility and usability for people with disabilities.

Documentation of core functions that cannot be accessed by persons with disabilities.

Documentation on how to configure and install the ICT item to support accessibility.

When an ICT item is an authoring tool that generates content (including documents, reports, videos, multimedia productions, web content, etc.), provide information on how the ICT item enables the creation of accessible electronic content that conforms to the Revised 508 Standards, including the range of accessible user interface elements the tool can create.

Before final acceptance, the contractor shall provide a fully working demonstration of the completed ICT Item to demonstrate conformance to the agency’s accessibility requirements. The demonstration shall expose where such conformance is and is not achieved.

Before acceptance, the agency reserves the right to perform independent testing to validate that the ICT solution provided by the contractor conforms to the applicable Revised 508 Standards.”

Along with consequences for those who do not provide an accessible solution, you should also define the method by which the solution will be measured. This will provide clarity to the respondent as to how their success or failure to comply will be measured and will serve as a well-defined method for measuring accessibility. Including past performance as a criterion for evaluation is another method for identifying those who understand accessibility and can provide a usable, accessible kiosk solution.

Additional kiosk recommendations

The following sources offer guidelines and include the laws and requirements put forth by various regulatory bodies on accessible kiosk regulations. The requirements, regulations, and guidelines listed below benefit those with hearing, visual, motor, and cognitive disabilities.

Section 508, Chapter 4: Hardware 402. Closed Functionality

The Access Board has written an ICT Refresh to address closed functionality. This primarily applies to Federally funded projects but can also be used to guide accessibility decisions outside of federally funded spaces.

Air Carrier Access Act

The Air Carrier Access Act provides detail applicable to Air Carrier kiosk deployments. In particular, the ACAA requires that one in four kiosks should be accessible in any area where kiosks are deployed.  Additional requirements are included above or outlined more fully in the suggestions for inclusion in the RFP above.

Voluntary Voting System Guidelines Version 1.1

Voting kiosks must be accessible. The Voluntary Voting System Guidelines Section 3.3 lists extremely detailed accessibility requirements and methods for meeting usability needs.  This document can provide additional specific details that can be required in the RFP but may provide too much granularity for a generic kiosk deployment.

WCAG (Web Content Accessibility Guidelines)

As mentioned above, the application should be developed to work with screen readers for users who are blind and who have low vision. As such, WCAG 2.1 Level AA are the appropriate guidelines for accessible applications. Level AAA guidelines should be implemented where feasible.  More information on kiosk application guidelines can be found in our article on the subject and directly on the WCAG website. These can be called out specifically or referenced generically in the RFP.

Writing a kiosk project RFP that will result in an accessible kiosk deployment

By including specific statements, penalties, measurements, and regulations/rules as part of an RFP, you can improve your chances of a better outcome. An RFP that includes accessibility features and requires those responding to the RFP to have more than a passing knowledge of accessibility (or have the ability to bring in a partner who does) can lead to fewer retrofits and potential restarts of the project due to low quality responses and inaccessible kiosk solutions.

Clear requirements will be helpful for comparing responses, as the kiosk accessibility standards will be included and will not cause additional cost variation based on those who have included accessible options and those who have not. When accessibility is optional rather than required, it is largely neglected and forgotten in the response and selection process. Require accessibility – and define it – and the resulting responses will be above the baseline for an accessible and usable kiosk deployment. If you need help either defining or meeting criteria for an RFP for an accessible kiosk, contact us today.


Need help with your specific accessibility needs?

Contact Us

Comments

Comments for this post are closed.