Does WCAG Apply to Kiosks?

In summary: yes, WCAG applies to kiosks.

Overview of Kiosk Accessibility Rules

Kiosk accessibility is largely guided by the Americans with Disabilities Act (ADA). The ADA sets forth hardware requirements and a few technical requirements for kiosks to follow in order to be considered accessible.  The ADA specifically offers guidance for ATMs and Fare Machines but was written and updated largely before self-service devices gained prominence. The main purpose of the ADA is to protect people with disabilities from being discriminated against and kiosk accessibility is broadly covered as it relates to functional design for disabled users.

The ADA does not provide any specific guidance on how to create an accessible kiosk apart from hardware. This means that the component and application specifics for building an accessible kiosk are currently not called out in the ADA but accessibility for disabled users is required by the ADA, regardless. To find out what constitutes an accessible kiosk, it is important to look to other regulations and guidelines, as they continue to be developed, improved, and referenced in litigation.

Specifics are outlined for Automated Teller Machines (ATMs) in Section 707 of the 2010 ADA Standards. Technical requirements included a call for speech output, privacy, tactilely discernible input controls, display screens, and Braille instructions.

Additional relevant regulations include Section 508, WCAG 2.1, the Air Carrier Access Act, and 255 Telecommunications. Section 508 applies to kiosks deployed or funded by the federal government.  From that, WCAG 2.1 can be used for accessible design purposes, though it is not specifically called for by the ADA. The spirit of the ADA calls for accessible design, and WCAG 2.1 delivers. The ACAA applies within transportation, specifically to air carriers, and 255 Telecommunication calls out audio requirements for blind and low vision users.

Section 508 are the Access Board’s Standards for electronic and information technology. Section 402 addresses closed functionality for ICT. Kiosks are an example of ICT with closed functionality, as a person with a disability is unable to add a keyboard, screen reader technology, or other assistive technology unless it is already provided on the kiosk. For security purposes, a kiosk prohibits someone from installing such as a screen reader.

From the Access Board summary on the ICT refresh,

“The existing 508 Standards require Federal agencies to ensure that persons with disabilities — namely, Federal employees with disabilities and members of the public with disabilities — have comparable access to, and use of, electronic and information technology (regardless of the type of medium) absent a showing of undue burden. 36 CFR Part 1194. . . Generally speaking, the existing 508 Standards take a product-based regulatory approach in that technical requirements for electronic and information technology are grouped by product type: software applications and operating systems; Web-based intranet and Internet information and applications; telecommunications products; self-contained, closed products; and desktop and portable computers.”

Additional clarification from the Section 508 Final Rule addresses WCAG 2.0 directly, and presumably will include the recently released WCAG 2.1 update when reviewed in future. WCAG provides A, AA, and AAA standards. These three levels are minimal (A), better (AA), and extensive (AAA) in the level of accessibility that is obtained through their respective requirements.  According to the final rule, user interfaces and applications should meet WCAG 2.1 AA standards.

For a complete list of these standards, visit W3.org.

Specific discussions of kiosks in WCAG documentation include:

Closed functionality has been defined as:

As noted in the Introduction, WCAG 2.0 assumes the presence of a “user agent” such as a browser, media player, or assistive technology as a means to access web content. Furthermore, many of the success criteria in WCAG 2.0 assume web content will be accessed by ICT that has assistive technologies connected to it, where the assistive technologies present the web content to the people with disabilities in accessible form. ICT products with “closed functionality” do not allow the use of some assistive technologies for all of their functions. In many cases such ICT products also lack a “user agent” or their equivalent. As a result, ICT following these success criteria by themselves will not make information accessible on ICT with closed functionality. Something else needs to be provided or be required in order to make the information addressed in these success criteria accessible. It is outside the task force work statement to say what the additional measures are, but this Note points out which success criteria depend on assistive technologies—and therefore would not work by themselves in products with closed functionality.

Because closed functionality, by definition, does not allow a user to attach assistive technology, WCAG success criteria that assume the presence of assistive technology will not facilitate accessibility as WCAG 2.0 intends. Where assistive technologies cannot be used, other output and input solutions are needed to achieve the intent of these success criteria.

Examples of products with closed functionality include:

• an ebook or ebook reader program that allows assistive technologies to access all of the user interface controls of the ebook program (open functionality) but does not allow the assistive technologies to access the actual content of book (closed functionality).
• an operating system that requires the user to provide log in credentials before it allows any assistive technologies to be loaded. The log-in portion would be closed functionality.
• a travel kiosk that provides an audio interface for blind and vision-impaired users as a built-in alternative to the visual interface and tactile keys as an alternative to touch screen operation for both blind users and those who can’t operate a touch screen.

WCAG calls out specific success criteria that may be difficult or problematic when deployed in a kiosk or or similar solutions with closed functionality. Appendix A: Success Criteria Problematic for Closed Functionality provides a list of these areas and the need for the use of assistive technologies to provide accessibility. In short, many of the criteria can be leveraged to make a kiosk accessible to a screen reader, but a screen reader must be provided on the kiosk, as it can not be “added” by a user agent ad hoc.

Appendix A is included in full below:

Appendix A. Success Criteria Problematic for Closed Functionality

The following success criteria will be problematic for developers of closed functionality. They either discuss making information available in text (which can be read by assistive technologies) or making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies) or discuss doing something else to make content compatible with assistive technologies. Alternate accessibility provisions that would be needed to address the purpose of these success criteria for the closed functionality aspects of products:

• 1.1.1 Non-text Content—requires text or a text alternative;
• 1.2.1 Audio-only and Video-only (Prerecorded)—requires a text alternative for time based media;
• 1.2.3 Audio Description or Media Alternative (Prerecorded)—one of the options available to authors for success criterion 1.2.3 is that of providing a media alternative that is text—which necessarily relies on a connected assistive technology to be presented;
• 1.3.1 Info and Relationships—requires information in a programmatically determinable form;
• 1.3.2 Meaningful Sequence—requires information in a programmatically determinable form;
• 1.4.4 Resize text—because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author;
• 1.4.5 Images of Text—because there is no need to impose a requirement on all closed functionality that text displayed on the screen actually be represented internally as text (as defined by WCAG 2.0), given that there is no interoperability with assistive technology;
• 2.1.1 Keyboard—requires operation via a keyboard interface which allows alternative input devices;
• 2.4.2 Page Titled—where software is an integral part of hardware that provides a single function, such as a calculator or IP telephone, there is no need for a title;
• 3.1.1 Language of Page—requires information in a programmatically determinable form;
• 3.1.2 Language of Parts—requires information in a programmatically determinable form;
• 3.3.1 Error Identification—while it’s important for errors that can be detected to be described to the user, for closed functionality, the error description doesn’t have to be provided in text, as defined in WCAG 2.0;
• 4.1.1 Parsing—the Intent of 4.1.1 is to provide consistency so that different user agents or assistive technologies will yield the same result;
• 4.1.2 Name, Role, Value—requires information in a programmatically determinable form.

Note 1: Some of the above success criteria would apply to systems with closed functionality if they are partially closed or if they allow for the connection of some types of devices. For instance, Success Criterion 2.1.1 Keyboard would apply to systems which have closed functionality to screen readers but which have a physical keyboard or a connector for standard keyboards.

Note 2: While these guidelines are not suitable for closed functionality as written, they will inform and aid development of built-in accessible alternatives needed with closed functionality.

Kiosk & Closed Functionality Assistive Technology

WCAG2ICT provides clear tools and guidance for developers to incorporate when building an accessible kiosk.  Good design will allow the kiosk app to be navigated by a screen reader. In a closed system, assistive technologies like JAWS and ZoomText should be included as a part of the kiosk solution and should be easily activated by a kiosk user in order to be accessible.  Navigation devices such as a Storm AudioNav pads or QWERTY keyboards should be included in order to allow for navigation (since a touch screen is not an easily accessible solution). Audio jacks should be provided in order to allow screen reader initiation and user privacy (rather than speakers which would broadcast user data. These assistive technologies should be standard in solutions (such as kiosks) with closed functionality, as they are necessary to providing an accessible solution for end users.

Read more about kiosk accessibility, JAWS Kiosk, and selecting the correct input device for your kiosk.