Fwd: Findable Help (Was status update)

Hi Rachael,

thank you for your mail, I would like to suggest some changes so we can achieve a great SC.

We all appreciate a consistent and easy-to-find help. So my proposals are:

Objection 1: From a customer point of view it would have been nice to have conformance statements on two levels. However, as you described, a conformance statement can be achieved with the current wording.

Objection 2: I see two options:
1) to change the order of the bullets, e.g. move self-help options to the top and order the bullets further down the more human contacts are involved.
2) to create a balance over all the bullets, meaning to provide examples for the self-help option as well, like "e.g. context help, application help, faqs".

Proposal:

----- 8< ----- snip ----- >8 -----
For single page apps or any set of web pages with blocks of content that are repeated on multiple web pages, at least one of the following is included or linked in a consistent location:

* Self-help option - e.g., context help, application help, documentation
* A fully automated chatbot that can:
  * recognize misspelled words,
  * provide human contact details if the chatbot is unable to provide a satisfactory response after 3 attempts,
  * be dismissed with a single interaction, and recalled using a link or button.
* human contact mechanism - e.g., messaging system,  contact form, social media channel
* human contact details - e.g., phone number, email address, chat client

Except for archival unsupported content which is clearly labeled as such, or where finding help would invalidate the activity.

Note: There is no requirement for a human to be available at all times.
----- 8< ----- snip ----- >8 -----


Objection 3: IMHO the level of WCAG 2.2 3.3.5 should be "A", because the availability of help in general is typically aligned with a higher priority and finding the help in a consistent way would be subordinate. Maybe this is just my guts feeling after reading the ISO standards for usability/accessibility. I had the impression that help is so important so it requires an extra standard section for reviewing the quality of help (9241-13).

best regards, Oliver.





On 1. Apr 2020, at 19:28, Rachael Bradley Montgomery <rachael@accessiblecommunity.org<mailto:rachael@accessiblecommunity.org>> wrote:

Hello Oliver,

I am trying to better understand the nature of these objections. To be clear, I'm answering this from a participant who worked on this SC vs. an AG chair.

The current SC text is:
For single page apps or any set of web pages<https://www.w3.org/TR/WCAG21/#dfn-set-of-web-pages> with blocks of content that are repeated on multiple web pages<https://www.w3.org/TR/WCAG21/#dfn-web-page-s>, at least one of the following is included or linked in a consistent location:

human contact details - e.g., phone number, email address
human contact mechanism - e.g., messaging system, chat client, contact form, social media channel
Self-help option
A fully automated chatbot that can:

  *   recognize misspelled words,
  *   provide human contact details if the chatbot is unable to provide a satisfactory response after 3 attempts,
  *   be dismissed with a single interaction, and recalled using a link or button.

Except for archival unsupported content which is clearly labeled as such, or where finding help would invalidate the activity.

Note: There is no requirement for a human to be available at all times.

If I understand correctly, Objections 1 and 2 center on the need for an option that does not require a human.  This SC as written allows for any of the options (human contact details, human contact mechanism, self help, or chatbot) to meet the criteria so an FAQ or How To help section would meet this SC as long as it is located in the same location within the prepackaged software, website, etc.  A current technique on this SC is an FAQ. We call out support pages as an option but would adding a technique for this make it clearer?

If not, how would you suggest we adjust the SC to meet this objection since we already allow self help documentation as a possible solution?

With regards to objection 3, the higher priority is intentional.  Reading through your details, is your concern that the new SC is level A or that 3.3.5 is AAA instead of A or AA?  If it is that the new SC is A, can you explain why it should be a higher level?

Thank you for these clarifications.

Rachael

On Wed, Apr 1, 2020 at 2:30 AM Keim, Oliver <oliver.keim@sap.com<mailto:oliver.keim@sap.com>> wrote:
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


--
Rachael Montgomery, PhD
Director, Accessible Community
rachael@accessiblecommunity.org<mailto:rachael@accessiblecommunity.org>

"I will paint this day with laughter;
I will frame this night in song."
 - Og Mandino