ADA Kiosk - WCAG Closed Systems Guidance- Comment Period

WCAG Guidance Closed Systems

Published on kma.global

Our notes and correspondence.

September 29th is last day to comment and best to do via the maillist — “[email protected]” <[email protected]>

Hi Craig,

The WCAG2ICT task force is glad you and other KMA members will be reviewing the WCAG2ICT First Public Working Draft.

In answer to the questions in your previous email to the list:

In the end, this document is just suggestions/recommended considerations regarding “closed systems” right?
Answer: Yes. This document is not intended to set requirements (is non-normative). It simply provides interpretation of WCAG Success Criteria when applied to non-web software and documentation. The task force makes notes where this may not be easily adaptable, as in the Success Criteria Problematic for Closed Functionality section. It also provides guidance and word substitutions when web-specific language is used in WCAG success criteria, which eases the interpretation. The intent is to help manufacturers as well as standards makers understand how widespread application of WCAG in non-web contexts can be done, yet to point out areas where such application may not be as easy – especially for closed functionality products where a user’s assistive technology cannot be installed.

We also want to call to your attention that WCAG2ICT 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 limitation of scope is listed in the Excluded from Scope section.

This doc is oriented to WCAG 2.2 right?
Answer: Yes. The first draft only has WCAG 2.1 since 2.2 is not yet a Recommendation. The next draft will include WCAG 2.2.
What are the other closed systems besides your typical kiosk (McDonalds self-order e.g.)
Answer: The task force has been thinking about a wide variety of products with closed functionality beyond the specific “systems” examples mentioned in the document. It is debatable whether maintaining a specific list in the document is useful since it could never be comprehensive and will become stale again over time. Examples the task force has considered include: printers, watches, iOT devices, telephones (including mobile and IP phones), smart speakers and televisions, set-top boxes (e.g. cable box, DVR), tablets, VR headsets, ATMs, PoS, and kiosks used for a variety of purposes (including travel kiosks used for ticketing and check-in).
What’s the deadline for providing comments and where do I send them?
Answer: The deadline for providing comments on this First Public draft is September 29. Comments can be made at any time before the WCAG2ICT update is a finalized Note by either sending comments to this mailing list or by opening GitHub issues in the WCAG2ICT document repository. “[email protected]” <[email protected]>

The task force appreciates that you took the time to post about the draft review and bring it to the attention of your colleagues in the KMA. Early public drafts provide the interim exposure to wider public review as the task force continues to develop content – a valuable part of the process.

Since this draft focused on including new WCAG 2.1 requirements and definitions to the 2013 WCAG2ICT, it’s not surprising you found old technology examples of closed systems. We are still making further changes that include: updates for Closed Functionality software, adding WCAG 2.2 requirements and definitions, addressing open issues, and refreshing stale content in other sections. We have noted the outdated examples that require updates in GitHub issue #217.

Best regards,

Mary Jo Mueller

IBM Accessibility Standards Program Manager

OUR COMMENTS

My contribution would be to focus on the low hanging fruit so to speak. Small kiosk projects are irrelevant. Large customer-facing transactional systems such as SCOs (Kroger, WholeFoods, etc) as well as the increasing number of customer-facing POS systems (Square, Toast, Bite, Oracle, etc). Hospitality is close by. EV charging and Smart City projects are rapidly increasing (and funded). Focus on self-service and terminals. “kiosks” is archaic and inherently vague (it could be an ATM for all we know).

You’ll need to point to/call out the Toshibas, Verifone, Ingenico, NCRs (Atlanta) and perhaps IBM to make any significant headway and make this doc an actionable recommendation. I am not sure that IBM and NCR will share that viewpoint….

There is still time as well for the US Access Board NPRM.

Thanks again for responding. I hope this document will serve as relevant tool for us in self-service unattended.

Actual Release

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 version 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. For that matter the modern TV (now up to 136″ thanks to LG).

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)

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 sufﬁcient 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 ﬁnancial 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

PostCounter: 111