FW: WCAG 2.2 status update

Hello Alastair, hello AGWG members,

for Findable Help we had a -1 vote and have objections, which we would like to present with this email.
Please excuse the length of this mail, we wanted to achieve sustainable progress in regard to find and access help content for software products.

Summary:
objection 1: Prepackaged applications do not have live support. It should be possible to give different statements for packaged software and productive live systems.
- software package: the VPAT states if the software provides features to fulfill the SC
- productive live system: the VPAT states if the live system supports human-based assistance.
objection 2: Most users are eager to help themselves (by using online help or documentation) before asking for human assistance. This should be reflected in the new SC.
objection 3: Findable help SC (level A) has a higher priority  than SC 3.3.5 Help (level AAA), which is the only WCAG SC asking for help.

Best regards,
Oliver (and Gundula)


Further Details:
No doubts, getting immediate access to help is vital. No matter if it is written or human assisted help.

However, from our point of view there is a hen-egg problem: The SC addresses human assistance where all the assistants need to be able to answer questions, which requires on the other side deep knowledge on the product being used. But how can a human or a machine answer questions if the WCAG SCs do not ask for documentation or online help, which is typically the resource to get skills about a product.

Before end users may want to have human assistance most humans are eager to help themselves, especially in a work environment, where employees have intentions not to ask for human assistance, for whatever reasons. This requires written help is provided and identified on a user interface. The offering for human assisted help complements the above.

To provide the best assistance to the user we see the following priorization in providing help:
1. context help is directly available from the UI (please recall the use of F1 in older programs in the 1990s)
2. application help is directly available in the application (like Help menus, help view, help window).
3. self-help options on base of the information which context and application help provide: faq, chatbot, etc.
4. human assistance, access pages (form-based, forums, etc)
5. human assistance, based on direct access via phone, or online chat.

From a VPAT authoring point of view it is important to understand the difference between packaged apps and installed and running instances of apps (like cloud-apps in the web).

For packaged apps an accessibility tester can only check for information artifacts if online help is provided with 1. access to help, 2. help facilities (views, windows) and 3. help content (context & app help).

For packaged apps its not possible to check and validate direct human access methods, except for checking a contacts page. However, customers are installing and maintaining the systems, thus the customer defines the ways to access human assistance. Prepackaged apps can provide a place where the customer can add the information, however, we are not sure if this would fulfill the SC in its current form.

From this point of view it seems to be helpful to divide the SC into
a) Help facilities & content are provided by the app and aligns to ISO requirements.
b) The Help content (context help, app help) can be found and accessed in the app.
c) Findable Human Assistance in operative systems is granted by the organization running the tool.


Our objection to this SC is that the user must have the possibility to find online help, in other terms help which is worth the term. In current WCAG 2.2 SC 3.3.5 asks for Help, the detail description then refers to “context help” and the context help is also restricted to a minimum of information on the context (such as a simple label which explains an input, for example, would fulfill the SC). In addition the SC is prioritized with level AAA, which does not match the level of the SC “Findable Help”. Finding Help has a higher priority than the SC it may ask for (3.3.5, level AAA), which may lead to confusion when implementing, specifically because software development (developers, managers, etc) simply do not fulfill AAA SCs in their products.

Another SC requiring online help or online documentation, as required from ISO and OS platform standards (for a list see the end of the mail) does not exist.

However, information presented in help is essential for all users, but it is especially important to accessibility, for a number of reasons. Three major reasons are:
1.) Users with impairments can learn from the help documentation which other options a user interface may offer to complete a task, or even more important, how to *exactly* operate the user interface element in focus.
2.) Testers for Accessibility require comprehensive documentation for identifying areas which may not be accessible to everyone, so the testers can then judge if alternatives are provided or if certain features are simply not accessible. This judgement can only be manifested if clear and precise information is available, otherwise judgements would be based on assumptions, which should be avoided.
3.) People providing human assistance (or creating tools for doing so) require a source for the information to be given to the people who ask for.

According to help systems designed in the early 1990s (and later became part of ISO 9241) we divide between context help and application help. While application help describes the purpose of the tool and the tasks to accomplish, the context help provides information based on the UI element being operated on the user interface, independent of using keyboard, mouse or touch. Context help not only offers information of the UI element in the context of the application, it shall also expose information on how the UI element in focus is to be operated, similar to operation manuals of cars and operating dashboard gadgets. For example, a UI element, like a combobox, is named and explained in every detail, to allow end users becoming effective and efficient to a max.

Compared to operation manuals of devices the software product documentation often lacks information on contextual level, like having information how a standard control or even worse, a custom control, can be operated using different input devices, like keyboard, mouse, touch, and in future maybe speech.

When we all use UI elements today we often use it based on the principle of "Trial and Error", which is not a wise method to operate software products which might have critical functionalities and severe consequences when used the wrong way (imagine products for hospitals, governments, military). Instead there should be clear and precise descriptions on how a control (like a button) is used and how it can be undone if needed, spanning the full functionality of a control (such as symmetric undo on using a mouse/touch/keyboard).

Information on such a level of detail has also a great advantage for accessibility: it allows to judge precisely if controls implement congruent interaction, so a click- and drag-based selection matches a tap- and drag-based selection on the touch devices and shift+arrow-keys allow a range selection. These are basic principles to make software usable, predictable and reliable. If a tester has a precise description she/he can judge, otherwise a decision would have to base on asumptions.

For custom controls (where an additional SC is open) the context help would help to indicate and describe features of custom controls to end users and accessibility testers. A sustainably maintained help content enables to test and validate custom controls. Methods for help content are provided in the standards mentioned in the Appendix:

Appendix: List of Standards, which define the context for Help or Documentation Content:
* ISO 9241-13 (Usability Standard, User Guidance, Chapter 10 "Help")
* ISO 9241-151 (Guidance on Web Interfaces, Chapter 10.2 "Providing Help2)
* ISO 9241-171 (Usability Standard, Section Accessibility)
* ISO 26531 (Testing and Review of user documentation)
* IBM System Applications Architecture, Common User Access (SAA/CUA, 1991)
* Microsoft Windows 95 Styleguides
* Apple Human Interface Guidelines
* Section 508, 1194.41 a, b, c

From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Sent: Montag, 30. März 2020 20:57
To: Niemann, Gundula <gundula.niemann@sap.com<mailto:gundula.niemann@sap.com>>
Cc: WCAG list <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: WCAG 2.2 status update

Hi Gundula,

Each of the SCs in the recent approvals has through multiple survey / discussion rounds and we got to the end of the comments made, so it is hard to know what you are referring to.

Could you give me some clues about which SCs, and what hasn’t been discussed yet?

We would need to make an assessment about whether the points are severe enough to warrant a step back in the process, or whether they would be best answered during a wider review.

Also, I am assuming we can and will be making updates to the associated documents (understanding/techniques) prior to going into the draft, when I said ‘approval’ for the recent ones that was for the SC text*.

Kind regards,

-Alastair

* Also, in our process there will be a CFC for the SC text + documents before it goes up, but we do want to resolve anything outstanding before that stage.


From: Niemann, Gundula

Hello Alastair, hello Wilco,

we also see some points that should be discussed and don’t seem to have been discussed before.

Best regards,
Gundula