Re: Findable Help (Was status update)

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> 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>
> *Sent:* Montag, 30. März 2020 20:57
> *To:* Niemann, Gundula <gundula.niemann@sap.com>
> *Cc:* WCAG list <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

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