Suggestions about - Making Content Usable for People with Cognitive and Learning Disabilities W3C Working Draft 17 July 2020. Ceapat, Imserso. Spain.

[claraceapat]

Dear Mr / Mrs, First of all, let me introduce myself. My name is Clara Delgado and I work as a speech and language therapist at Ceapat. Ceapat is The National Center for Personal Autonomy and Technical Aids of the Institute for the Elderly and Social Services (Ministry of Social Rights and Agenda 2030) in Spain. www.ceapat.es Ceapat's mission is to promote the rights of people with disabilities and the elderly through activities based on providing information and advice on assistive products and universal accessibility. Ceapat has an interdisciplinary work team made up of professionals from different fields such as architects, occupational therapists, psychologists, engineers, etc. Among other activities, we usually participate in standardization groups at ISO (international level) or UNE (national level). Specifically, I am currently participating in different standardization groups related to cognitive accessibility (ISO) and Easy to Read (ISO; UNE). Through this email, I would like to share with you some comments on “How to make the content usable for people with cognitive and learning disabilities”. W3C Working Draft July 17, 2020 ( https://www.w3.org/TR/coga-usable/#abstract )

The main objective of sending you my comments and suggestions is to contribute with my experience on cognitive accessibility and Easy to Read to improve the document. I hope you find them useful and let me apologize if my English is not very accurate. Most importantly, you understand the general meaning of the comments and suggestions I want to share with you and consider them based on my experience working with people with cognitive, language and learning disabilities. Congratulations for this work that will surely help to make web sites much more understandable and accessible. I am at your disposal for any clarification or comment that you consider necessary to send me. Best regards. Clara I. Delgado Santos

1

Working Draft: Abstract Comment/suggestion: From my point of view, maybe it would be interesting to indicate at the beginning of this document, that people with cognitive and learning disabilities can also have another difficulties such as motor disabilities or visual disabilities. For that reason, this guidance should be follow keeping in mind this premise and applying other guidelines about accessibility as well. This is important mainly related to the use of assistive technology for accessing to technological devices/websites: e.g. eye tracking access, joysticks, trackballs, scanning and switch devices, mouse pointer software by movement of head, etc. If a person cannot access "physically" to the site/device and using it the most independently way possible, the person will not use the site, even if the site is designed following recommendations about cognitive accessibility.

[claraceapat]

2

Working Draft: 1 - . Introduction “Making websites and applications that are friendly for people with cognitive impairments affects every part of design and development. (…) people with cognitive impairments. Often the issues that affect people with cognitive and learning disabilities include design, context, structure, language, usability, and other factors that are difficult to include in general guidelines. Some design patterns create barriers for people with disabilities. The patterns presented in this document have been designed to avoid such barriers for people with cognitive and learning disabilities. While this guidance may improve usability for all, these patterns are essential for some people with cognitive and learning impairments to be able to use content independently.” Comment/suggestion: In the introduction, but also along the whole document, it is used indistinctly "people with cognitive impairments", "people with cognitive and learning disabilities”, "people with disabilities" and “people with cognitive and learning difficulties”. These different ways to refer the users appear along the whole document. That means that, sometimes the subheading seems to apply to “people with disabilities”, others to “people with cognitive impairments” and so on. From my experience I have noticed that using these changes of terms is confusing for some professionals, mainly if they are not used to work or to have professional contact with people with cognitive and learning disabilities. Moreover, it would be taken into account that not all people with disabilities have cognitive and learning disabilities (e.g. some people with visual/motor disabilities) and also, not all people with cognitive and learning disabilities are people with disabilities (e.g. seniors). From my point of view, it would be clearer and consistent with the title of the document if the same term is used along it, that is to say, using only the term “people with cognitive and learning disabilities”. Moreover, there is a good explanation about people with learning and cognitive disabilities in the subheading 2.2.

[claraceapat]

3

Working Draft: 3.7 Objective 7: Provide Help and Support 3.7.1 User Story: Help As a user who often cannot use a website I want to be able to get help and give feedback easily from every place where I get stuck. This ensures I am not excluded and the site is aware of my needs. This also includes the following user needs: (…) Using my preferred communication method (form, email, chat, phone support, etc.) that are being provided, and it is accessible to me. (…) 3.7.2 User Story: Support As a user who often cannot use a website I sometimes need in-page and inline support so that I am able to use the content. This also includes the following user needs: As a user who struggles with text and words, help and support should include symbols or enable me to personalize using my own (…)

Comment/suggestion: From my point of view, the methods of communication included as examples should be related to the users’ needs mentioned in 3.7.2. That’s to say: Writing communication (form, email, chat), oral communication (phone support). Moreover, it should be included communication thorough pictograms because this way of communication is mentioned in 3.7.2 as an example of user needs, as you can see in the highlight text.   In short, my proposal would be to write it in the following way:   Using my preferred communication method: writing communication (e.g. form, email, chat), oral communication (e.g. phone support, video call) or pictogram communication, (symbols included or enable me to personalize them), that are being provided, and it is accessible to me.   On the other hand, this argument could be also applicable to 4.8.5.2:   4.8.5.2 Description Make it easy for the user to ask for help or report issues at any point in the process. This includes: Easy to Use: Feedback information and forms are simple and clear. (User Testing with different user groups is highly recommended.) Easy to Find: Available from any place where the user may get stuck   Using my preferred communication method: writing communication (e.g. form, email, chat), oral communication (e.g. phone support, video call) or pictogram communication, (symbols included or enable me to personalize them).   Instead of: Using a preferred communication method such as a form, email, chat, or phone support (…)   In this regard, I would like to add an element that I have not found to be included and that I consider to be important. I It is in reference to the "contact" with the organization / company of the website. In many websites, the contact information is located at the bottom of the page, in a very small space and difficult to see, along with other information such as: legal notice or terms and conditions.   I believe that the contact information should appear in a more visible place for the person. This indication, in addition to offering greater visibility to the organization, offers the person more security in the use of the website, since they will find more easily how to contact a person in charge of the organization/service provided, etc.

[claraceapat]

4

Working Draft: 3.7.5 User Story: Task Management As a user who struggles using web content due to executive function impairment and/or struggle with numerical concepts, I want to be confident that I can manage my tasks. This also includes the following user needs: Explanations for unusual controls in a form I find easy to use (such as a video or text). (…) Comment/suggestion: I consider that it would be more complete if it is added: "in easy to understand language". (See comment 7) My proposal would be to write it in the following way: Explanations for unusual controls in a form I find easy to use (such as a video or text in easy to understand language).

[claraceapat]

5

Working Draft: 4.3.2.3. - How it helps There are times where how to open the sub-menu item may not be easy for some with cognitive disabilities. If the control to expand a menu item relies on a particular gesture or way of rolling over the area with a mouse, for example, the end user may not figure out how to expand the sub-menu and may abandon the task. An example would be a menu that expands only after moving the mouse over a particular side of the menu text.

Comment/suggestion: The last example is highly important. Sometimes, how to interact with the different elements on the web could be difficult for the user. Not only for the fine motor skills required to do it, but also due to the visual feedback received on the screen when the interaction is carried out. Some menus expanded that suddenly are hidden if the mouse is moved, are extremely confusing for the person.   My proposal would be to add more detail in the following way:   There are times where how to open the sub-menu item may not be easy for some people with cognitive and learning disabilities. If the control to expand a menu item relies on a particular gesture or way of rolling over the area with a mouse, for example, the end user may not figure out how to expand the sub-menu and may abandon the task. An example would be a menu that expands only after moving the mouse over a particular side of the menu text. Therefore, easy manage to interact with the site is also an important aspect to take into account.

[claraceapat]

6

Working Draft: 4.4.1.2 Description ·       Use common and clear words in all content. Look at the most common 1500 words or phrases. These are the terms that people with severe language impairments are most likely to know. ·       Remove unnecessary words. ·       Do not invent new words or give words new meanings in your application. Do not expect people to learn new meanings for words just to use your content. If you must create new terms, make sure the user has access to an explanation within one click or event. (…) Comment/suggestion: I suggest to add some more:   - Use the same word or expression to refer the same element or action along the site. That’s to say, avoid to use synonyms (e.g. use “request” and “application” referring the same one). Some persons with language disability can confuse them and think that they refer different things.   I also would add:   - Avoid using abbreviations or acronyms, both in the mother language or from foreign language if they are not frequent and well known in the country.   Abbreviations are difficult to read for people with language disability, because they have to read the letters of the abbreviation, to associate them with the corresponding whole word and the most important thing, understand the meaning. For them, it is easier to understand a text if all words are whole written. For example: It is better to use “39 Victoria Street” than “39 Victoria St.”   Moreover, an abbreviation is included in an example in 4.8.6.4. 4.8.6.4 Examples Use: (…) Avoid: Consistent reference to points of the compass including less well known ones (e.g. N by NE) (…) However, I suggest better: Consistent reference to points of the compass including less well known ones (e.g. North by Northeast)   Related to acronyms, they are mentioned an example of difficulties for people with brain injury in 4.9.2.3.:   4.9.2.3 How it Helps (…) For example, a user with traumatic brain injury has executive function and memory impairments impacting their ability to remember details such as: (…) What an acronym stands for; (…)   I also would add another statement in 4.4.1.2:   - Avoid words from other languages, unless they are well known and frequently used.   It is a widespread practice in the websites to use words from other language, mainly in English language. It is true to say that, living in a globalizing world, a lot of words are commonly used across different countries and they are frequently well-known. However, people with language disabilities can struggle to understand the website if these type of words are excessively used on it.   Sometimes, these words are difficult to read (mainly aloud) if they are not resemble the phonetics of the mother tongue. As a result, user can find the site difficult and incomprehensive, giving up the use of it If there is a need to use words from another language, it should be ensured that they can be read (pronounced) based on the similitudes between the phonetic systems of both languages, and also that they are well understood by the users (to understand the meaning).

[claraceapat]

7

Working Draft: 4 .4.1.6 Examples Use: Plain text with clear words and definition of term. (…) Comment/suggestion: As the same explained in comment 2, along the document is used a variety of expressions to refer "easy to understand language" such as: "plain language", "plain text" , "Easy to Read", “easy reading”, “simple language”, “easily to understood language” or “plain and friendly language”. As I commented, the use of such a variety of terminology may be enriching for reading, but in that case, it can become confusing for professionals who are approaching cognitive accessibility for the first time. Due to the fact that, the main goal is to achieve the comprehension of the whole text of the site (also considering the design and the user interaction with the site), it could be useful to use the expression "easy to understand language", which includes (in general): the visual perception function (related to design), readability of the document (including also aspects related to design) and reading comprehension (the meaning). Moreover, Plain Language and Easy to Read are well known and both have some standard guidelines in common and some different. Personally I consider that, in some recommendations, could be more appropriate to use Easy to read guidelines, and in others it could be enough to take into account Plain Language. As a matter of fact, from my point of view, maybe it would be more accurate if an alternative version in Easy to Read is mentioned as an important key to include when the site contains long/complex texts (e.g. instructions about how to fill a form to make a complaint).   This could be mention/included in 4.8.2.2:   4.8.2.2 Description Provide content in easy to understand language that helps users understand complex information. This should include redundant information for different user groups such as: ·       Summaries and step-by-step information in Easy to Read  plain language ·       Explanation in Easy to Read of choices and any disadvantages (…)

[claraceapat]

8

Working Draft: 4.4.3.4 Examples Use: Write clearly. Avoid: Do not write unclearly. Comment/suggestion: I consider that the examples related to 4.4.3.4 are mentioned in 4.4.3.3. In my opinion, the examples included in 4.4.3.4 are not too much clear.

[claraceapat]

9

Working Draft: 4.4.9.2 Description In instructions, separate each step. Separate steps make instructions much easier to follow. Consider: Including all steps, even those you think are "obvious;" Comment/suggestion: This recommendation is extremely important, so maybe I would add a short explanation about it, such as: Including all steps, even those you think are "obvious", avoiding in this way the need to infer information by the user. Or Including all steps, even those you think are "obvious", avoiding in this way that the user needs to infer information.

[claraceapat]

10

Working Draft: 4.4.11.2 Description Do not overlay words on busy backgrounds. Provide an option to remove background noise behind auditory content or ensure background sounds do not interfere with the main auditory content. For text: Use solid backgrounds for blocks of text. Comment/suggestion: The best visual contrast between background and text colour is highly important, not only for people with visual disabilities, but also for people with language disabilities, people with Brain Injury Acquired or people with colour blindness among others. Using bright colours, using too many colours, or using low contrast to each other can be distracting for the person. I propose to add this reference: Use solid backgrounds for blocks of text, assuring the adequate contrast between them. https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced https://www.w3.org/WAI/WCAG21/Understanding/use-of-color

[claraceapat]

11

Working Draft: 4.5.4.2 Description Choose a form design that reduces the chance that the user will make a mistake. This includes: ·       Design the form so that the user needs to enter as little information as possible; ·       Clearly indicate required fields; Comment/suggestion: It is a very widespread practice in websites to indicate, at the beginning of a data request form, that a red asterisk means that the fulfilment of a certain field into it is mandatory. Thus, throughout the form, you can see fields such as "name and surname", or "contact telephone number", which include a red asterisk at the end of them. These types of indications, despite being clear, since they are explained at the beginning of the form, force the user to remember what they mean every time they find a red asterisk. This can be complex for people with memory difficulties. Thus, when the completion of a field is mandatory, it would be helpful if the user can read this indication in every field that this is needed, so avoiding the constant requests that the form itself will ask for him/her once and again until that these type of fields are full filled. My proposal could be is to say: Clearly indicate the required fields each time you need them, even if that indication is redundant.

[claraceapat]

12

Working Draft: 4.6.1.4 Examples Use: An application lets the user decide how they want to be notified about reminders and emails. Users can choose visual reminders and/or sounds, or none. They can flag users as essential contacts who can interrupt in more cases. These settings are easy to find from every screen. For some users, not having any notifications enables them to focus on a task and then go to their emails or calendar when the task is completed. Comment/suggestion: I would add a little more features of these settings: These settings are easy to find and to understand how to use them from every screen.

[claraceapat]

13

Working Draft: 4.7 Objective 6: Ensure Processes Do Not Rely on Memory Do not put barriers that stop people with cognitive disabilities from using or getting to content. Sometimes developers put a menu barrier between users and the task they are doing so users cannot use the content or service. (…) Comment/suggestion: Perhaps I think that it would be more suitable to move on these paragraphs to “Introduction”. They are not too much specific about the content explained in subheading 4.7 and besides, the term “barriers” is mentioned in “Introduction”, as you can see: (…) Some design patterns create barriers for people with disabilities. The patterns presented in this document have been designed to avoid such barriers for people with cognitive and learning disabilities. While this guidance may improve usability for all, these patterns are essential for some people with cognitive and learning impairments to be able to use content independently. (…)

[claraceapat]

14

Working Draft: 4.7.1.3 How it Helps (…) They may also struggle with other steps of login, such as: ·       Entering characters in the correct order; ·       Entering characters correctly on the first try (resulting in being locked out). ·       Finding a PIN; ·       Working out puzzles or distorted letters; Comment/suggestion: I am not sure if "working out puzzles" refers to the presentation of photos and the demand to select which ones contain an object. That is a usual requirement to access some webpages to ensure the user is not a robot. This kind of demand could be high difficult to carry out for users with brain injury, for example, due to hemianopia. Also for users who cannot deduce which object is if only is seen one part of it. The photos usually show a part of an object but also sometimes a landscape with a lot of things in it (in order to locate one specific object). Both tasks can be complicated. One of the reason is that the object is not the same in each photo (e.g. locate "ships", but different types of them). They are dissimilar so the user needs to deduce what objects are considered as thee same even if they are showed in different ways. Also, some are shown a little blurred, with landscapes (e.g. streets) from countries different from to the users', and in general, they are presented very close to each other.   According to the previous, maybe I would add:   They may also struggle with other steps of login, such as: ·       Entering characters in the correct order; ·       Entering characters correctly on the first try (resulting in being locked out). ·       Finding a PIN; ·       Working out puzzles or distorted letters; ·       Selecting objects hidden in photos           On the other hand, this type of login (or checking to ensure you are not a robot) could be explained in more detail in 4.7.3.-   4.7.3 Pattern: Provide a Login Alternative with Less Words 4.7.3.1 User Need As a symbol user, I need a login process I can use that does not rely on a lot of words   I also suggest to include some recommendations that could be taken into account if this type of demand is required. That is to say, the use of the photos would be a good way to login/check the user is not a robot,  if it is taken into account that: - It is asked for locating the same object always with the same appearance - It is not used a landscape or photos with a lot of things in the background and it is requested to locate an object into it - It is not used blurred photos - It is not use landscapes or objects which can be more commonly knowns in some countries than others (e. g. the road sign "stop" is the same all over the world. However, a garbage container does not and its shape, sizes, colour, etc., may be different depending on the country and even the city) - It is used photos of objects taken from the front, avoiding using other more visual complicated perspectives, such as from the side, from above, from below, etc. - The photos have good quality - They are not place extremely together, and the distance between them and also its position on the screen (e.g. in a horizontal row, in vertical row) can be selected by the user, using settings related to it.

[claraceapat]

15

Working Draft: 4.7.2 Pattern: Allow the User a Simple, Single Step, Login I need the login process to be simple, and not multi-step. Related User Story: Accessible Authentication. Comment/suggestion: I think the heading “User need” is missing. If this heading is added, the following numbering should be modified.

[claraceapat]

16

Working Draft: 4.7.4.3 How it Helps Many people cannot use voice menu systems and other complex systems. This often stops people from completing critical tasks by themselves. Often this can include making doctors' appointments, getting health insurance, reaching social services, getting their water turned back on, etc. Comment/suggestion: I suggest including among the examples the telephone companies as well. They are in charge of offering internet access and it is common for them to use a previous (and complex) voice menu system.

[claraceapat]

17

Working Draft: 4.7.5.3 How it Helps (…) Good practice that dd reduces the memory skills required include: (..) Comment/suggestion: There is a type mistake.

[claraceapat]

18

Working Draft: 44.9 Objective 8: Support Adaptation and Personalization (...) One use-case we would like to see is providing interoperable symbol set codes for non-verbal users. Products for people who are non-vocal often use symbols to help users communicate. These symbols are in fact people's language. Unfortunately, many of these symbols are both subject to copy write and are not interoperable. That means end-users can only use one device, and can-not use apps or AT from a different company. An open set of references for symbol codes for these symbol sets however, could be interoperable. That means the end user could use an open source symbol set or buy the symbols and use them across different devices or applications. Symbols could still be proprietary but they would also be interoperable. Comment/suggestion: I am not sure about the expression used in the paragraph, but could it mean “copyright” instead of “copy write”? On the other hand, I would like to share you information about a resource with Licenses: CC (BY-NC-SA) about Augmentative and Alternative Communication, which includes a database of pictograms. (http://www.arasaac.org/condiciones_uso.php) It could be also mentioned as a complementary information about AAC in 4.9.4.3

[claraceapat]

19

Working Draft:  4.9.3.2 Description Support simplification of your content. Often this includes allowing the user to: ·       Get less test or more simple text; Comment/suggestion: There is a type mistake, “text” instead of “test”

[claraceapat]

20

Working Draft: 5.5.4.1 Differences from Usability Testing with the General Population There are some differences when performing usability testing with people who have cognitive impairments: ·       Ask ahead of time if they need any support for their needs. This could include a quiet room or frequent breaks. (…) Comment/suggestion: I suggest to add an important reminder that it is key in the test process: - Explain to the users that the aim of the task is to test the site and not to test their abilities   I consider the need to include it, because it is mentioned in the same subheading (number 8) when it is said:   If the user is struggling, remind them that you are reviewing the system not them and that their insights are really helpful. (…)

[claraceapat]

21

Working Draft: 5.5.4.1 Differences from Usability Testing with the General Population (…) 1.     3. Check that the testers understand the task or question. Encourage your testers to “think out loud” Comment/suggestion: I would add “read aloud” too. It is a good way to observe, if the user is reading the text properly and even so, the user has difficulties to understand it, or the user is struggling to read the text and, as a result, it is not understood by him/her. In the first case, it would be important to review the text in order to become it more comprehensible. There is to stress that the task is not to evaluate the user ability comprehension, but the how the text is written in order to be understood by people with cognitive and learning disabilities. In the second case, the user maybe need to use another way to understand the content, such as using text  - to - speech to listen it or/and using images, pictures.   My proposal is:   3. Check that the testers understand the task or question. Encourage your testers to “read aloud” and “think out loud”

[rachaelbradley]

Thank you for your really detailed and helpful review. We have tried to address as many of your points as we can. Here are the details: 163.1 - we will add to the introduction: “Note that people with cognitive and learning disabilities may also have other impairments such as motor disabilities or visual impairments. For example, an individual with age related forgetfulness may also require higher contrast. It is always important to follow WCAG and ensure the needs of all disabilities are addressed.” 163.6 We are adding to pattern 4.4.1 "use clear word" as follows: “Remove or explain uncommon acronyms, abbreviations, and jargon." We are also adding to the examples: Use: “Acronyms that are not in common use, are explained the first time they are used, and are in an acronym tag with a title after that.” “Jargon that is avoided or explained.” Avoid: “Acronyms and jargon that the user may not know.” Issues 163.2, 163. 7, 163.8, 163.14, 163.17, 163.19: We have edited the document to meet these suggestions. This includes making the terms more consistent. Specifically, we intend to use the term "easy to understand language" as suggested in 163. 7. For 163.14 We have added the missing heading to section 4.7.2. 163.3, 163.4, 163.5, 163.9, 163.11, 163.14 163.16: These suggestions have asked to expand some sections. However we need to balance this with the need against other requests to shorten the document. Most of them we felt had been covered elsewhere in the document and we were not convinced of the benefit of making the document longer. We also felt 163.16 was out of scope for this document and that 163.11 is covered in WCAG and ARIA. 163.13 (part of the introduction) is especially difficult to change, without very strong arguments as it was written via consensus meetings between different groups in the W3C. 163.18 Thank you for the information about arrosac, we are indeed aware of it. 163.12 163.20 163.21: More research would be needed for these suggestions to be included. We would be delighted if you could point us in the right direction or contribute to them. We could then try to get them in to a next version (2.0). With thanks, The task force

[claraceapat]

Thank you very much Rachael! Of course, you can consider my proposals or other equally interesting to improve the document. The most important thing is that it is clear and useful to everyone. Thanks for your kindness.