Re: List of Proposed Changes in Content Usable

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
>

Received on Wednesday, 20 May 2020 10:34:59 UTC