WCAG and Closed Systems Guidance
WCAG has always been about the open web. For closed systems some of WCAG (3 instances) are included in the U.S. Access Board recommendations for closed systems. In 2013 the W3C issued this same document (but using WCAG 2.0). This is the updated versions for WCAG 2.2. This document is “guidance” (566 pages) on how WCAG 2.2 can apply to Ebooks, Operating systems, and Travel kiosks (example given). There is no mention of ATMs or hybrid POS SCO systems or POS terminals which would seem to be the majority of closed systems.
We do note there is a specific recommendation for kiosks regarding the timeout period (see below).
It should be noted that the DOJ has issued NPRM regarding Web and Mobile accessibility. In their NPRM they use WCAG 2.1 Level AA which is current release. It will be different though and not reference WCAG 2.2 .
The committee is still finalizing Appendix A and is accepting comments from any interested parties. We are commenting and if you would like yours included email to [email protected]
Background
Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT), approved in September 2013, described how WCAG 2.0 could be applied to non-web documents and software.
Abstract:
This document, “Guidance on Applying WCAG 2.2 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) 2.2 [WCAG22] and its principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).
This document is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the WCAG2ICT Overview.
Editors:Mary Jo Mueller (IBM)Chris Loiselle (Oracle Corporation)Phil Day (NCR)
Excluded from Scope
The following are out of scope for this document:
- This document does not seek to determine which WCAG 2.2 provisions (principles, guidelines, or success criteria) should or should not apply to non-web documents and software, but rather how they would apply, if applied.
- This document does not propose changes to WCAG 2.2 or its supporting documents; it does not include interpretations for implementing WCAG 2.2 in web technologies. During the development of this document, the WCAG2ICT Task Force did seek clarification on the intent of a number of the success criteria, which led to clarifications in the Understanding WCAG 2.2 document.
- This document is not sufficient by itself to ensure accessibility in non-web documents and software. As a web standard, WCAG does not fully cover all accessibility requirements for non-user interface aspects of platforms, user-interface components as individual items, nor closed product software (where there is no Assistive Technology to communicate programmatic information).
- This document does not comment on hardware aspects of products, because the basic constructs on which WCAG 2.2 is built do not apply to these.
- This document does not provide supporting techniques for implementing WCAG 2.2 in non-web documents and software.
- This document is purely an informative Note about non-web ICT, not a standard, so it does not describe how non-web ICT should conform to it.
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 login 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.
See Appendix A: Success Criteria Problematic for Closed Functionality for a list of success criteria for which this is relevant.
Timeout Criteria
20 seconds was also based on clinical experience and other guidelines. 20 seconds to hit ‘any switch’ is sufficient for almost all users including those with spasticity. Some would fail, but some would fail all lengths of time. A reasonable period for
requesting more time is required since an arbitrarily long time can provide security risks to all users, including those with disabilities, for some applications. For example, with kiosks or terminals that are used for financial transactions, it is
quite common for people to walk away without signing off. This leaves them vulnerable to those walking up behind them. Providing a long period of inactivity before asking, and then providing a long period for the person to indicate that they are present can leave terminals open for abuse. If there is no activity the system should ask if the user is there. It should then ask for an indication that a person is there (‘hit any key’) and then wait long enough for almost anyone to respond. For “hit any key,” 20 seconds would meet this. If the person indicates that they are still present, the device should return the user to the exact condition that existed before it asked the question.
PDFs
