Comments from EO - Githubissues

EOWG Input for COGA TF Document title: Making Content Usable for People with Cognitive and Learning Disabilities (W3C Working Draft 17 July 2020) Document URL: https://www.w3.org/TR/coga-usable The Accessibility Education and Outreach Working Group (EOWG) reviewed the excellent document developed by the Cognitive and Learning Disabilities Accessibility Task Force (COGA TF). EOWG participants reviewed and discussed comments about the document. We are impressed and grateful for the work - thank you! Our goal is to support broad awareness of the material and to facilitate ease of adoption and use. We compiled and summarized comments in areas of general agreement and recommendation. This document does not include all individual EOWG participant comments. COGA may receive additional comments as GitHub issues that are not included here. Recommendations included are high level and mostly address the organization and presentation of content. Some EO participants distributed the document to their own teams and we included relevant feedback in these recommendations. Universal response is overwhelmingly positive. Practitioners recognize the timeliness of the work and its potential to improve how digital communicators understand and address cognitive issues. We hope our suggestions will help make content clearer, easier to find, and more usable.
A common observation was “This is document about making content usable is not itself very usable, even for people without disabilities.” (Disclaimer: This does not represent consensus from all EOWG participants — we didn’t have enough time to go through that process, especially given August schedules.) Summary of recommendations EOWG recommends:  COGA TF and EOWG work together to improve existing information throughout the WAI website to encourage and support designers, developers, project managers, policy makers, and others providing better accessibility for people with cognitive and learning disabilities.  Focus the Content Usable document on designers, developers, and writers. Point to other resources on the WAI website for information on business case, including accessibility throughout projects and organizations, usability testing, policy information, and background on cognitive accessibility. (Which can be updated for coverage of cognitive accessibility, per above.)  Provide the information in a more consumable way than a single TR doc.  Address specific suggestions for improving the usability of the Content Usable document.

Integrate content into existing WAI website resources Rationale: TR documents are not often found and used by developers, designers, and content authors. (We assume that is the intended audience for this document.) In usability testing, users reacted negatively to TR docs.[1] A goal of EO work on the WAI website and resources was to make accessibility easier and less confusing than many TR documents. EO participants and WAI staff actively promote WAI website resources through conference presentations and other outreach efforts. Practitioners will not know to look for this kind of guidance in TR space. Integrating throughout the WAI website will lead more people to learn about cognitive accessibility, even if they weren’t looking for it. Top priority resources to improve for coverage of cognitive accessibility:
Cognitive Accessibility at W3C • See: Draft analysis for expanding this resource or creating a new resource
How People with Disabilities Use the Web — 3 sub-pages • Open issue on Updating (possibly expanding) coverage of cognitive and learning disabilities • Example update: In Stories of Web Users page, add link to web version of Content Usable Personas section
Relevant Perspectives Videos
Accessibility Principles Other WAI website pages with relevant information: • Involving Users in Web Projects for Better, Easier Accessibility • Involving Users in Evaluating Web Accessibility • Planning and Managing Web Accessibility • Accessibility, Usability, and Inclusion • The Business Case for Digital Accessibility • Older Users and Web Accessibility: Meeting the Needs of Ageing Web Users
Focus Content Usable on designers, developers, and writers Rationale: The length of the document will be daunting to many people. If we can integrate the less technical aspects of the document into the main WAI website, the content can then be focused on the most important target users of designers, developers, and writers. It is doubtful that managers who may care about the business case or UX researchers who may care about the usability content will look for or find the content relevant to them in a document of this kind. EOWG has also worked hard to avoid covering topics in multiple places on the W3C website. Instead, we seek to put the information in one place, and point to it there from other places where it is relevant. Therefore, we have the following input: 2.1. Appendix: Business Considerations
Remove the Appendix: Business Considerations and The Aging Population as a Market.
In the Introduction, add a 1-3 sentences that introduces the relevance for cognitive accessibility and points to the following (with their potential updates from the COGA TF): • The Business Case for Digital Accessibility https://www.w3.org/WAI/business-case/ • Older Users and Web Accessibility https://www.w3.org/WAI/older-users/ 2.2. Background about People with Learning and Cognitive Disabilities and the Web
Remove the section 2.2 Background about People with Learning and Cognitive Disabilities and the Web.
In the Introduction, add a 1-3 sentences introduction that points to the following (with their updates from the COGA TF): • Cognitive and learning disabilities section of Diverse Abilities and Barriers in How People with Disabilities Use the Web https://www.w3.org/WAI/people-use-web/abilities-barriers/#cognitive • (maybe) Accessibility, Usability, and Inclusion https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/ 2.3. Building the User into the Development Process and Usability Testing Background/Rationale: Most of Section 5 is either already covered in existing WAI resources or was deemed beyond the scope of what W3C/WAI resources should cover. Usability testing is a large topic – whole books are written on it. Including participants with disabilities in usability testing is a big topic – multi-page resources are written on it. WAI previously decided that it was important to provide a resource on the WAI website that introduced and strongly encouraged including users, e.g., in usability testing -- and that we would briefly introduce the most important points, and not cover other issues or the topic in general. (References: Analysis/Requirements and Changelog for “Involving Users in Web Accessibility Evaluation and Requirements/Analysis and Changelog for Involving Users in Web Development) The draft of section 5 goes beyond what WAI determined was in W3C’s scope. Additionally, there would be several problems with extending the scope to include this information. For example, Section 5.3 Informed Consent does not use common terminology, does not cover important issues, and has information that some usability professionals might disagree with. EOWG input:
Remove the sections 2.3 Building the User into the Development Process and remove sections 5.1-5.4 of Usability Testing, Focus Groups and Feedback. In the Introduction, add a 1-3 sentences that introduces the relevance for cognitive accessibility and points to the following (with their potential updates from the COGA TF): • Involving Users in Web Projects for Better, Easier Accessibility https://www.w3.org/WAI/planning/involving-users/ • Involving Users in Evaluating Web Accessibility https://www.w3.org/WAI/test-evaluate/involving-users/ • (and maybe Planning and Managing Web Accessibility https://www.w3.org/WAI/planning-and-managing/ )
For sections 5.5.1-5.5.8., make it clearer that they directly relate to a specific one of the “Objectives”. In the interactive web version, consider providing these in an expandable section on the Objective page.
Draft idea for section 5 text: Section 5: Including users in design and usability testing It is particularly important to include real people with cognitive and learning disabilities in projects. See the following resources on including people with disabilities (“users”): • Involving Users in Web Projects for Better, Easier Accessibility: • describes how involving people with disabilities early in web projects helps • provides guidance on how to involve users throughout your project, including in planning, designing, and developing • Involving Users in Evaluating Web Accessibility: • encourages informal evaluation early • provides guidance on including people with disabilities in a range of evaluation, including usability testing These resources encourage you to get a range of people with different disabilities to participate in your project. To understand the range of cognitive and learning disabilities, see the Cognitive and learning disabilities section of Diverse Abilities and Barriers in How People with Disabilities Use the Web. For developing materials such as consent forms and usability test task descriptions, use the design patterns under Objective 3: Use Clear and Understandable Content. The following sections provide specific questions to help evaluate if the design patterns under each Objective are achieved. [content from 5.5.1 – 5.5.8] 2.4. Appendix B: Considerations for Uptake in Different Contexts and Policies Rationale: This section was confusing to most reviewers. First of all, it is lengthy and complex. (The reading grade level is 15-18.) Reviewers noticed significant repetition and lack of focus. Several questioned the relevance of this content to our understood target audience for this document. While the points are valid, the section does not seem to fit. Most reviewers did not find a logical connection to the other content. As a result, EO proposes to strengthen the policy information around COGA issues in the existing WAI resources and to include a shorter statement within this document that points to it. EOWG input:
Remove Appendix B: Considerations for Uptake in Different Contexts and Policies.
In the Introduction, add a few sentences that more clearly and succinctly provides guidance on using this document in policy and other contexts. For example, see wording under 4.1. How to use this document below.
Provide the information in a more consumable way than a single TR doc Rationale: Some EOWG participants were comfortable having all the Design Guide information in one document. However, others in EO found the size of the document discouraging to explore and hard to navigate. Again there were comments about how the title of “making content usable” was contradicted by the presentation itself and said they would hesitate to pass it along, despite the clear accuracy and value of the content. They felt that their teams would simply not use it in this format, based on input from colleagues they shared the document with. Additionally, it was very difficult to find specific information and print out just that information. EOWG has heard the strong preference of the COGA TF to publish as a Working Group Note under w3.org/TR. EOWG understands that preference and does not object. That said, EOWG strongly encourages the information to also be provided in a “web version” that enables users to more easily get to specific information, distribute it to focus on one part at a time, print it, etc. [1] Has some usability testing findings related to TR docs.
Specific suggestions to improve usability Rationale: There is so much important, useful, and needed information in this research and work. EOWG strongly believes that the current structure creates barriers to a broad use and adoption of its guidance. We suggest that such barriers can be addressed through some basic changes in approach and structure. 4.1. How to use this document
Rewrite section 2.1 “How to Use this Document” to provide guidance for designers, developers, and writers on how to use the document.
Move “Following the advice in this document as much as possible will be particularly valuable for Web content and applications that address: … [list]” to the main part of the Introduction or a separate section.
Draft idea for section 2.1 1 How to Use this Document: This document provides information to help website creators make content more usable and accessible for people with cognitive impairments. The high-level objectives outline key design goals that will help people with cognitive impairments. Each objective has associated user needs, stories, personas, and design patterns. The document is divided into parts that can be used by different groups and in different documents to support content development. For example, • User needs could be incorporated into requirements specifications • Design patterns could be used in design guidelines or included in design libraries • Design patterns can help in developing content guidelines to promote plain language • User stories and personas can be used to inform design activities such service walkthroughs The Objectives and Overview section maps the user needs, personas, and patterns together under each objective. This provides a way to understand how to address the objective and why it is important. 4.2. Summary, Appendix A: Mapping User Needs, Persona and Patterns, Introduction, Objectives Use case: Several EO participants has significant difficulty understanding the sections and their relationships, getting an overview of the content, and navigating around the document. When they finally arrived at Appendix A: Mapping, they reacted: “This is great! Now it makes sense! This should be near the top of the document.” In discussing it, we understood that the document has too much information for many of us to process linearly, and having it in the tables helped understand the Objectives and showed how the pieces relate much better for many of us. Use case: One person skipped the Summary and when right to the “1 How to Use this Document” section. She was then confused what the Objectives were. Another person was also unclear about the Objectives, thinking they were Objectives for this document itself. EOWG input:
Put the Introduction first.
Change “Summary” to something like “Objectives and Overview”. Start with a simple explanation of what the Objectives are. Make each objective a heading. Include the explanation that’s currently in the Summary. Then put the table that’s currently under Appendix A. (Here’s a rough mockup to show the organization that we’re thinking of – although it doesn’t have the first sentence explaining the Objectives.)
In the tables, also link the User Stories and Design Patterns. Note: Several EOWG participants suggested adding another column to the tables that lists which WCAG SC or Guideline it relates to. We didn’t look at the content enough to figure out the specific relationships and if EO as a group wanted to suggest this. 4.3. Icons in Summary Rationale: Unclear icons can be a distraction for users who struggle to understand them. This could be frustrating for some readers. And is counter to the goal of this document to improve accessibility for people with cognitive disabilities, who often need useful images. (EOWG has spent significant effort to come up with appropriate icons that everyone was comfortable with for several resources, e.g., for abilities, media, tables, a/v, process, business case. We are hesitant that it is feasible to come up with meaningful icons for all of the Objectives, without significant time and effort from the TF and additional input from reviewers.) EOWG generally liked the format of the summary with icons. However, some participants had issues with some of the icons, particularly 1, 3, 7 and 9. • (1) Help users understand… -- confusing, seems like steps backwards. • (2) Help users find… -- OK. conveys “search”, which may or not be what COGA wants to communicate? • (3) Help users understand with clear text and images… -- cannot figure out what it is trying to communicate. • (4) Provide support for different ways to understand content. -- complex and confusing, one EOWG participant thought the top right was a clock and didn’t understand the relevance. • (6) Help users to maintain focus. -- looks like cross-hairs on a target, and could be disturbing for some people. • (7) Ensure processes do not rely on memory. -- no ideas what this is trying to communicate. • (9) Support adaptation and personalization. – uncomfortable, feels like things pointed at me from all directions. • (10) Test with real users! -- OK. communicates older users. A minor point is that it would improve readability to have the hanging indent after that images, so text doesn’t wrap under the images. If you can develop meaningful, intuitive icons that support the concepts, then EOWG suggests that you use them throughout the document to help communicate the relationship of the information. For example, include the dialog icon in 3.7, 4.8, A7 (Given EOWG’s struggles with icons, we assume it is best to not try to have them at all.) 4.4. Relationship to WCAG Rationale: Several EO participants missed the information about WCAG altogether. Some didn’t understand it. EOWG input:
In the Introduction, add a subheading such as “Not WCAG Requirements” before the paragraph “The Objectives and Patterns presented here provide supplemental guidance beyond the requirements of WCAG….” 4.5. Objectives unclear Use case: From the Summary - “I had difficulty understanding objectives 1 and 3. They seemed like mangled, but then I concluded objective one talks about conventions (consistent identifiers) and 3 talks more about clear language and signs.” 4.6. Headings repetition Use case, screen reader user: “While reading the table of contents, I find it irritating to read in several sections, titles that have the same text” Non-screen reader user: “Repeated use of 'Pattern' and 'User Story' adds quite a bit of clutter.” 4.7. Persona names Important: Please change some persona names so diverse ethnicities are included. Use case: “Following our discussion on gender specific documents, when I read user scenarios I have the impression that the users are more female names than male names and wonder if it is author's' intention?” See also Personas and use cases in the WAI Style Guide 4.8. QA review and copy edit EOWG found some of the wording unnecessarily complex. For example, in one measure, the Introduction gets Reading Grade Level 15 and Appendix B gets Reading Grade Level 18. For the reputation of this document, WAI, and W3C, it is especially important that this document — which instructs on clear and simple language — also uses clear and simple language. Additionally, there are several inconsistencies throughout the document, grammar errors, typos, and things that do not meet the WAI Style Guide. Examples: • Some objectives in the Summary section are not the same as the ones described in the “User stories” and the “Design Guide”. • “learning and cognitive disabilities”, “cognitive and learning disabilities” • “Web page”, “Webpage”, “web page” • “the user”, “the users”, “users” — examples: • “5.5.1 Does the User Understand What Things Are and How to Use Them?” “5.5.2 Can Users Find What They Need?” • “5.5.4 Can Users Avoid Mistakes and Easily Correct Them” “5.5.5 Can the Users Maintain Focus?” EOWG recommends a thorough copyedit to: • simplify the language • fix grammar errors and typos • provide consistency within the document and with the WAI Style Guide [1] Appendix: W3C WAI website usability testing findings Participants described the process of using [a TR page] as: “you go to the page, scroll down, scroll down, scroll down, about four or five screens, past all the useless stuff, and then you get to the good stuff. Which is great. But it's always in the middle part of a really, really, really long page.” Participant quote about W3C TR doc: “…confusing to read. Has great info, there's a lot of it. Not organized in a user friendly way. Really hard to navigate. And find the info I'm looking for. Very text heavy. It's organized like a book with a table of contents, maybe not that way. Maybe should have separate pages for separate things instead of jump down the page.” Finding 4: Participants' ability to locate task-specific information was significantly hindered by the “front matter” at the start (and close) of the [/TR/] documents… Participants consistently expressed negative reactions… the initial sections (document's development status and history), were a significant barrier to participants' ability to identify the relevance of the document, comprehend its content, and to navigate within the document. Participants uniformly stated that whenever they attempted to read a [/TR/] document, they had to first, in one participant's words: “scroll past a ton of irrelevant information about who wrote the document, why, when it was written, and when it was modified.”… More at: https://www.w3.org/WAI/redesign/ut_report/findings.html#finding4

w3c / coga

Comments from EO #199