Re: List of Proposed Changes in Content Usable

One last change that came in. There is a new sentence in the abstract so it
reads:

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. This guidance
is not required for sites that conform to WCAG, but is valuable additional
information for sites that wish to provide increased
accessibility to users with cognitive or learning disabilities.  The
Objectives and Patterns  are designed to be informative and user friendly.

Best regards,

Rachael

On Wed, May 20, 2020 at 6:35 AM Steve Lee <stevelee@w3.org> wrote:

> Rachael
>
> thank you for all your hard work bringing these threads together and
> presenting them to the WG.
>
> Steve
>
>
> On 20/05/2020 03:06, Rachael Bradley Montgomery wrote:
> > Hello,
> >
> > Two additional changes were made based on today's AG meeting.  The word
> > "poor" was removed from the sentence "Poor design, structure and
> > language choices can make content inaccessible to people with cognitive
> > and learning disabilities." and the table in the appendix for testable
> > statements has been moved to the wiki with a link to it from the
> appendix.
> >
> > The version of content usable with all the changes is at:
> >
> https://raw.githack.com/w3c/coga/changes-from-ag-meeting-may-2020/content-usable/index.html#
> > The differences are visible in Github at:
> > https://github.com/w3c/coga/pull/115/files
> >
> > The full list of changes is below. We will discuss these at Thursday's
> > meeting.
> >
> > 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:
> >
> >       o people with learning and cognitive disabilities,
> >       o user needs,
> >       o user testing,
> >       o design patterns (ways) to make content usable, and
> >       o 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:
> >
> >       o people with learning and cognitive disabilities,
> >       o including users in design and testing activities,
> >       o aims and objectives for useable content,
> >       o design patterns (ways) to make content usable, and
> >       o 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:
> >
> >       o Cognitive Accessibility User Research
> >         <https://www.w3.org/TR/coga-user-research/>,
> >       o Cognitive Accessibility Issue Papers
> >         <https://w3c.github.io/coga/issue-papers/>, and
> >       o 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*
> >
> >     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 sitefor 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 toThe
> >     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.)
> >
> > *
> > *
> > 10. 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.
> >
> > *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.
> >
> > 11. 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
> >
> >
> > *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
> >         bedisabled. 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.
> >
> > *
> > *
> > 12. 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 groupscan achieve a large improvement
> > by asking people who they know, such as friends, colleagues, relatives
> > or neighbor
> >
> > 13. Appendix Appendix: Testable Statements for Each Pattern
> >
> > The testable statements have been moved to a wiki page.
> >
> > On Mon, May 18, 2020 at 5:06 PM Rachael Bradley Montgomery
> > <rachael@accessiblecommunity.org
> > <mailto:rachael@accessiblecommunity.org>> wrote:
> >
> >     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:
> >
> >           o people with learning and cognitive disabilities,
> >           o user needs,
> >           o user testing,
> >           o design patterns (ways) to make content usable, and
> >           o 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:
> >
> >           o people with learning and cognitive disabilities,
> >           o including users in design and testing activities,
> >           o aims and objectives for useable content,
> >           o design patterns (ways) to make content usable, and
> >           o 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:
> >
> >           o Cognitive Accessibility User Research
> >             <https://www.w3.org/TR/coga-user-research/>,
> >           o Cognitive Accessibility Issue Papers
> >             <https://w3c.github.io/coga/issue-papers/>, and
> >           o 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 sitefor 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 toThe 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
> >             bedisabled. 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 groupscan achieve a large
> >     improvement by asking people who they know, such as friends,
> >     colleagues, relatives or neighbors who :
> >
> >
> >
> > --
> > 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
> >
>
>

-- 
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