Re: FW: WCAG 2.2 status update

Hi Wilco
> EPUB SC about not limiting the SC to an arbitrary list of
publication types

The definition of electronic publication is a response to a request from
Shawn to limit the SC to the type of content that really concerned the epub
team rather than other types of web content.

The definition is standard
https://en.wikipedia.org/wiki/Electronic_publishing
I don't think the definition is arbitrary. Certainly we could find edge
cases to try to break the definition, but I think that is true for most
definitions in WCAG and everywhere else. I think identifying electronic
publications on the web with this definition would have a high inter rater
reliability among WCAG manual evaluators. It can't be automated easily,
which is true for much of WCAG.

The SC has its origins back to 4 years ago when the epub team first met
with WCAG working Group members.

I think the SC and its supporting documentation is mature, it's been
iterated for 8 months and is getting good support in its current form. If
you have a particular suggestion about a type of publication content that
you think is omitted or should be left out, feel free to make a
recommendation.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>


On Tue, Mar 31, 2020 at 6:59 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
>