List of Proposed Changes in Content Usable

Hello,

The COGA editorial group met today to review the document.

   - The document that was reviewed
   <https://raw.githack.com/w3c/coga/changes-after-0327/content-usable/index.html>
by
   AG
   <https://raw.githack.com/w3c/coga/changes-after-0327/content-usable/index.html>
   - The updated document
   <https://raw.githack.com/w3c/coga/responces-to-cfc-april-2020/content-usable/index.html#>

   <https://raw.githack.com/w3c/coga/responces-to-cfc-april-2020/content-usable/index.html#>
   - The changes are listed below.

We will discuss the results of tomorrow's AG meeting at Thursday's COGA
meeting but if you see a change that you disagree with, please respond to
this email before Tomorrow at 10 EST.

Thank you all.

Rachael


*List of Changes*

1. Revised the Abstract

*Original*

This document is for people who make Web content (Web pages) and Web
applications. It gives advice on how to make content usable for people with
learning and cognitive disabilities.

This document has content about:


   - people with learning and cognitive disabilities,
      - user needs,
      - user testing,
      - design patterns (ways) to make content usable, and
      - advice for policy makers.

This document builds on the Cognitive Accessibility Gap Analysis and Roadmap
<https://www.w3.org/TR/coga-gap-analysis/> , Cognitive Accessibility User
Research <https://www.w3.org/TR/coga-user-research/> and Cognitive
Accessibility Issue Papers <https://w3c.github.io/coga/issue-papers/> to
address user needs that are not met in technologies and accessibility
guidelines.

*Revised*

This document is for people who make Web content (Web pages) and Web
applications. It gives advice on how to make content usable for people with
learning and cognitive disabilities.

This document has content about:


   - people with learning and cognitive disabilities,
      - including users in design and testing activities,
      - aims and objectives for useable content,
      - design patterns (ways) to make content usable, and
      - personas (examples) and user needs.

The Objectives and Patterns presented in this document supplement the
Success Criteria presented in the WCAG accessibility guidelines and address
those user needs that are not fully met in accessibility guidelines. They
are designed to be informative and user friendly. They build on the:


   - Cognitive Accessibility User Research
      <https://www.w3.org/TR/coga-user-research/>,
      - Cognitive Accessibility Issue Papers
      <https://w3c.github.io/coga/issue-papers/>, and
      - Cognitive Accessibility Gap Analysis and Roadmap
      <https://www.w3.org/TR/coga-gap-analysis/>.

2. Reorganized the Document

*Original*

1. Summary
2. Introduction
  2.1 Background about People with Learning and Cognitive Disabilities
3. Design Guide
4. Building in the User
4.1 Process
4.2 Usability Testing, Focus Groups and Feedback
5. Use Cases/Persona
6. User Stories


*Revised*

1. Summary
2. Introduction
2.1 Background about People with Learning and Cognitive Disabilities
2.2 Building the User into the Development Process (Note: This was 4.1
Process)
3. User Stories
4. Design Guide
5. Usability Testing, Focus Groups and Feedback
6. Use Cases/Persona

3. Changed #3 in Summary (Editor team please double check)

Changed "*Use clear and understandable text and images." to "**Help users
understand with clear text and images.* "

4. Revised the Introduction

*Original*

Making websites and applications that are friendly for people with
cognitive impairments affects every part of design and development.

Traditionally accessibility focused on making the interface usable for
people with sensory and physical impairments (vision, hearing and/or
mobility). Some accessibility features will help people with cognitive
impairments, but often the issues are about context, language, usability,
and other more general factors that impact everyone to some degree.

This document aims to provide guidance on how to make websites and
applications that are friendly for people with cognitive impairments by
providing guidance for your designs and design process.


*Revised*


Making websites and applications that are friendly for people with
cognitive impairments affects every part of design and development.

Traditionally, accessibility focused on making the interface usable for
people with sensory and physical impairments (vision, hearing and/or
mobility). Some accessibility features will help people with cognitive
impairments, but often the issues that affect people with cognitive and
learning disabilities about context, structure, language, usability, and
other factors that are difficult to include in general guidance.

This document aims to provide guidance on how to make websites and
applications that are friendly for people with cognitive impairments by
providing guidance for designs and the design process.

5. Changed 3 sentences in 2.1 Background about People with...

*1. Original*

People with cognitive and learning disabilities may not be able to
effectively use web content because of the design and content choices of
the author.


*1. Revised*

Poor design, structure and language choices can make content inaccessible
to people with cognitive and learning disabilities.

*2. Original*

However, for users with cognitive and learning disabilities, these
difficulties are likely to be persistent and significant, so that they are
unable to access content and may be forced to abandon tasks, without any
way to complete them unaided.


*2. Revised*

However, for users with cognitive and learning disabilities, these
difficulties are likely to be persistent and significant. As a result, they
could be unable to access content and complete these tasks unaided.


*3. Original*

People may also experience a co-occurrence of difficulties such as
dyspraxia / developmental coordination difficulties and ADHD should also be
taken into account.


*3. Revised*

People may also experience a co-occurrence of difficulties such as
dyspraxia / developmental coordination difficulties. People with ADHD may
also be helped by some of these techniques.

6. Revised Design Guide Introduction
*Original*

Making websites and applications friendly for people with cognitive and
learning disabilities affects every part of design and development.

Accessibility has traditionally focused on the making the user interface
usable for people with sensory and physical impairments in vision, hearing
and/or mobility. Some accessibility features that help these user groups
also help people with cognitive impairments. People with cognitive and
learning disabilities also need improvements to context, language,
usability, and other more general factors that impact everyone to some
degree. As a result, they do not fit well into traditional accessibility
standards.

This document provides assistance making websites and applications friendly
for people with cognitive and learning disabilities by providing you with
guidance for your designs and design process.

This guide is divided into design themes. Each theme includes user stories,
testing methodologies, and design checkpoints. Just understanding the
themes and user stories may help you make your content more accessible to
some users with cognitive and learning disabilities. Please see the section
on user testing for guidance on how to perform cognitive accessibility user
testing.

EDITOR'S NOTE
Please note this document is not the final draft. We are still working on
harmonizing the content and the internal consistency of the terms and
style. The task force also intends to redo the tables to make them
consistent with the design patterns (such as in 5.1 and 6.1). In addition,
design patterns 2.8, 2.9, 2.6 and 2.10 2.13 and 5.3 and 5.6 need to be
checked for overlap. In addition, we are exploring the addition of these
sections:

Items for further research;
Data driven systems - gathering and analyzing user feedback and data;
Special applications such as sections on GPS systems, conversational
interfaces.
Comments and feedback are most welcome.

*Revised*

This guide provides assistance making websites and applications friendly
for people with cognitive and learning disabilities by providing guidance
for designs and the design process.

The Objectives and Patterns presented here supplement the Success Criteria
presented in the WCAG accessibility guidelines and address those user needs
that are not fully met in accessibility guidelines.

This guide is divided into design themes. Each theme includes user stories,
testing methodologies, and design checkpoints. Just understanding the
themes and user stories may help you make content more accessible to some
users with cognitive and learning disabilities. Please see the section on
user testing for guidance on how to perform cognitive accessibility user
testing.


7. Changed Success/Failure Examples to Do/Don't (Also want to add icons
before but that isn't done yet)
*Original*

Examples
Success example: Headings tell me exactly where I am.

Failure example:


   - Headings do not clarify the steps in a form;
   - A page heading reads "Service not available." The user has to remember
   what they were doing to know what service this is about.

*Revised*

Examples
Do: Headings tell me exactly where I am.

Don't:


   - Headings do not clarify the steps in a form;
   - A page heading reads "Service not available." The user has to remember
   what they were doing to know what service this is about.

8. In 3.7.1 Pattern: Provide a Login...
We corrected a typo from "coping" to "copying"

9. Revised C Appendix: Guidance for Policy Makers

   - We changed the title from "Appendix: Guidance for Policy Makers" to
   "Considerations for uptake in different contexts and policies"
   - We removed the Table of design patterns and policy criteria
   - Added the following text to the beginning:

Many agencies and services are required to use plain language and to be
usable by vulnerable groups. This document will help content developers
know what to do to achieve this goal across different geographical areas
and include user groups of people with learning and cognitive disabilities.
In addition many sites want to reach user groups such as millennials with
learning disabilities and people with age appropriate forgetfulness. This
can be because of their commitment to inclusion, or to enable growth in
these high value, under-serviced, markets. Typically, there are many more
people in the target audience with a cognitive or learning disability then
the content provider is aware of, and many content providers are often
losing these user groups.

This document is not normative or designed for wide applicability for all
websites and contexts. There are sites that may choose not to follow some
or all of the advice in this document. For example, a Web site for
accountants may disregard any advice on accommodation for people who do not
understand numbers, whilst realizing that many of their colleagues have
other learning or communication impairments and age appropriate
forgetfulness. (In contrast conformance to The Web Content Accessibility
Guidelines (WCAG) <https://www.w3.org/WAI/standards-guidelines/wcag/> is
required by law in many countries, and is designed to enable clear
conformance and wide applicability for all web content.)


*Three Additional Proposals based on Document Review for Tone*

1. Under Objective 8, is the following paragraph:

*Current Text*

People with cognitive disabilities often use add-ons or extensions as
assistive technology. This includes spell checkers, passwords support, and
support for text-to-speech with synchronized highlighting of the phrase
being read. It is important that developers do not disable these tools.

I think it would be good for us to reword the last sentence (highlighted).
It could be read as the developers disable their own tools vs writing code
that disables them.

*Proposed Text*

People with cognitive disabilities often use add-ons or extensions as
assistive technology. This includes spell checkers, passwords support, and
support for text-to-speech with synchronized highlighting of the phrase
being read. It is important that these tools are supported and work on all
content. In other words, content should not include code that disables
these tools.

2. In the same section under More Details it states:

*Current Text*

People with cognitive disabilities are often using add-ons as assistive
technology. It is essential that add-ons and similar tools work. Otherwise,
we need to make the author support all the functions of the add-ons in use
as assistive technology.

Exceptions:
When there is a security or safety requirement, these API's may be disabled
for the relevant field
If it breaks the main function of the site, such as evaluation and testing
applications

I think the "we need to make the author.." part could be better worded and
this is the only place we have exceptions (a very WCAG word) included.

*Proposed Text*

People with cognitive disabilities often use add-ons as assistive
technology. It is essential that add-ons and similar tools work, except
when:


   1. A security or safety requirement requires these API's be disabled. In
   this case they should be disabled only for the relevant field(s).
   2. The add-on breaks the main function of the site, such as evaluation
   and testing applications.

 When add-on's are automatically disabled by the code, the burden of
supporting the extra functionality of the add-ons falls to the author.


*3. Under 4.2.1 Finding People to Include*

*Current Text *
Alternatively, small developers can achieve a large improvement by asking
people who they know, such as friends, colleagues, relatives or neighbors
who :

*Proposed Text*
 Alternatively, small development groups can achieve a large improvement by
asking people who they know, such as friends, colleagues, relatives or
neighbors who :