Re: FW: WCAG 2.2 status update

Wilco & David,

To clarify, in hopes of opening a path forward for this: I did not request
an explicit list of things like books and magazines and I agree that doing
so inherently leaves things out when this kind of guidance should also
apply.

I gave the feedback at TPAC that the wording offered then seemed entirely
too prescriptive around UI controls for page numbers when talking about all
content on the web. The use case offered (teacher: "Please turn to page
57") needs addressing, but it seemed like the guidance only considered that
one use case without considering the implications for other kinds of
content and other environments, scenarios, etc. From there, the wording
changed to pagebreak locators, which I don't particularly like - it seemed
like just swapping one word for another in still very prescriptive guidance
without regard for the broader implications for scope outside of epubs. In
short, I very much agree with what you wrote:

On the other hand I think the definition of pagebreak locators is too
> generic. This SC seems to be about numbered pages, but by the genericness
> of the current language, quite a few things could apply here too.


I suggested earlier that it seemed this SC would need to change in one of
two ways (I very much prefer the first):

   1. Research and consider the broader context of use cases that seem
   similar to "Please turn to page 57" and rewrite the guidance to something
   that can cover the needs of people with disabilities in the larger scope of
   other contexts and content, as well as the narrow scope considered so far.
   2. Narrow the scope of guidance to the scope so far considered: ePUB and
   related formats, turning to a specific place consistently across the
   formats.

Hope that helps!

-Shawn

On Thu, Apr 2, 2020, 5:50 AM Wilco Fiers <wilco.fiers@deque.com> wrote:

> Hey David,
>
> Firstly, I want to just acknowledge the work that has gone into this. 8
> months of work is a lot, and it is really cool that you and others are
> putting in the time.
>
> What I mean when I say "arbitrary" is; why is it this list? Why does it
> include a magazine article and not a news article (unless it's a newspaper,
> I guess)? Why a textbook and not a manual? Why a journal and not a diary? I
> disagree with Shawn that this should be defined based on content type. The
> needs for PWD don't change based on the type of content they are reading.
>
> There are other things that I think need to be addressed too. The use of
> the word "page" and "set" in the pagebreak locator definition. The EPUB
> world may have its own idea of what a page is, but in WCAG terminology an
> EPUB is a single web page, not a set of web pages. The definition of web
> page does not allow that reading. If it did, 2.4.5 Multiple Ways would be
> very difficult to meet for EPUB.
>
> On the other hand I think the definition of pagebreak locators is too
> generic. This SC seems to be about numbered pages, but by the genericness
> of the current language, quite a few things could apply here too. For
> example the publication date on a news article is arguably a pagebreak
> locator. It's a visual marker, arranged in a sequence, showing the location
> in a set of pages.
>
> The latter I think is where the solution might be too; if this was limited
> to visual or programmatic page numbers, it doesn't much matter what is or
> isn't an electronic publication. The SC could be something like this: When
> regions in a web page have visual or programmatic numbering (such as the
> page numbers of an e-book), provide a mechanism to navigate to the region.
> You could maybe put in an exception for numbered headings if you want.
>
>
> Kind regards,
>
> On Wed, Apr 1, 2020 at 6:52 PM David MacDonald <david100@sympatico.ca>
> wrote:
>
>> 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 <(613)%20806-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
>>>
>>
>
> --
> *Wilco Fiers*
> Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>
>