Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This document is for people who make Web content (Web pages) and Web applications. It give advice on how to make content useable for people with learning and cognitive disabilities.
This document has content about:
This document builds on the Cognitive Accessibility Gap Analysis and Roadmap, Cognitive Accessibility User Research [coga-user-research] and Cognitive Accessibility Issue Papers [coga-issue-papers] to evaluate where user needs remain to be met in technologies and accessibility guidelines.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document was published by the Accessible Platform Architectures Working Group and the Accessibility Guidelines Working Group as a First Public Working Draft. This document is for people who make Web content (Web pages) and Web applications. It gives advice on how to make websites and applications that are friendly for people with cognitive impairments by providing guidance for your designs, and design process.
To comment, file an issue in the W3C coga GitHub repository. If this is not feasible, send email to public-cognitive-a11y-tf@w3.org (subscribe, archives). Comments are requested by 14 January 2019. In-progress updates to the document may be viewed in the publicly visible editors' draft.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by groups operating under the W3C Patent Policy. The groups do not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures (Accessible Platform Architectures Working Group) and a public list of any patent disclosures (Accessibility Guidelines Working Group) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 February 2018 W3C Process Document.
This section is non-normative.
Making websites and applications that are friendly for people with cognitive impairments affects every part of design and development.
Traditionally accessibility has been most focused on the interface, and making that usable for people with sensory and physical impairments in 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.
Some aspects of making things friendly for people with cognitive impairments are best dealt with as part of the overall design process. For most organizations there should be scope for taking a user-centred design process.
Key parts of this process for people with cognitive impairments should be:
If people with cognitive impairments are included in the usability testing and their feedback is accounted for, you can be sure that the website will be easier to use for everyone. (See Usability testing, below)
How much effort an organization should expend on making a website friendly for people with cognitive impairments will vary. For organizations that provide public services, or are national (or international) private service providers and already conduct user-research, they should:
For organizations that do not include usability testing as part of the process, they could use this document to review designs and implementations.
People with cognitive and learning disabilities may be unable to use web content because of the design choices of the author. Examples include:
User needs for people with learning and cognitive disabilities (COGA) are often important for other users. However for COGA groups they often make the difference between being able to use the site or not be able to use it at all.
This summary is based on the user need addressed in https://rawgit.com/w3c/coga/master/gap-analysis/table.html. We may add user needs from the design requirements
Any time there is a 'target audience', there will be people with with learning and cognitive disabilities in that audience. Cogntiive issues are often invisible in day to day life until people encounter particular challenges. To provide some context and understanding eight personas have been created which outline fictional people with various cognitive issues and the challenges they face.
Usability testing is the best way to know if your content and functionality works for real people with cognitive and learning disabilities.
Usability is a key factor for everyone, if something is difficult to use it is cannot be accessible. Automated testing for accessibility tends to focus on more technical areas of accessibility, and cannot assess how easy something is to use. It is vital for people with cognitive disabilities that teams do not rely on automated testing alone for accessibility, but incorporate design requirements, and if possible test with people who have cognitive disabilities.
Finding people to include in usability testing who have different learning and cognitive disabilities can be relatively easy, such as friends, colleagues, relatives or neighbors who:
It is beyond the scope of this document to provide a guide to usability testing and user-research, however, there are many resources available such as:
There are some differences when testing for accessibility, and that includes when testing with people who have cognitive impairments:
Ensure that the participation forms are easy to understand, send them to the participant in advance, and allow plenty of time for the participant to ask questions and fill in forms;
Allow the participant to bring a carer, family member or friend to attend with them. If your tester has a guardian you should get informed consent from both the tester and their guardian;
It helps to provide easy methods of assessing mood, rather than asking for the participant to verbalise, try asking them to select a smiley face, such as:
Ensure the person does not feel like they are at fault for making mistakes; this is a likely scenario for people with cognitive impairments.
The next few paragraphs up to the next section may be removed as it is both covered in usability guidance in the links above and significantly incomplete in comparison. We would be interested in finding out if anyone finds it useful to include.
Some brief guidance on usability testing:
How can you make it better for your users ( people with learning and cognitive disabilities)
If the user if failing blame the designer and not the user. Such as “ it is so helpful that you are doing this because our designers are not very good, or are always playing computer games so they think everyone is good at this stuff” or “you are really helping us make this useable by real people and not just engineers” . Stop the process if users are getting distressed despite this.
As a short overview, usability could be measured based on efficacy, efficiency and satisfaction. This can be done by measuring or tracking:
At the end of the evaluation you should be able to answer:
Note you will need to get informed consent from the tester before testing. Explain what they will be doing and why it is helping you. If there are any risks they need to be explained and understood. If your tester has a guardian you should get informed consent from both the tester and their guardian. Make sure potential participants are aware they can withdraw from the testing situation at any time and that their comments will be anonymised before being used in any report.
(With thanks to Smart4MD for this overview. I SMART4MD is co-financed by the European Union under an EU Framework Programme for Research and Innovation – Horizon 2020, with grant agreement number 643399.and the European commission for this contribution.)
To help web content providers meet the needs of people with cognitive and learning disabilities we have identified the following themes:
Design so that as many users as possible understand the site and know how to use it. This often involves using things that are clear and familiar to the user so that they do not have to learn new symbols, terms or design patterns. Personalization and good use of semantics can help make the symbols and design as familiar to the user as possible. People with cognitive disabilities rely upon predictable behavior in digital content. For example, many websites do not follow the standard convention for hyperlinks: blue = unvisited; purple = visited; and underlined. See the design requirments for understandable design.
Help the user find what they need. Navigating the system should be easy. See the design requirments for navigation.
Use clear and understandable content This includes clear text, clear images, speech, and easy to understand video. See the design requirments for understandable content.
Prevent the user from making mistakes and make it easy to correct mistakes when they do occur. A good design and use of scripts will make errors less likely, but when they do occur the user should know how to correct them, without having to render other data or start from the beginning. See the design requirments for errors.
Help the user focus and restore context if attention is lost. Items like breadcrumbs can help orientate the user and help the user restore the context when it is lost. (Making breadcrumbs clickable can also help the user undo mistakes.) See the design requirments for focus.
Minimize the cognitive skills required to use the content and avoid barriers that stop people with cognitive disabilities from using content, such as hard to use security mechanisms. When possible, provide more accessible options. See the design requirments for barriers.
Provide help and support. Graphics, summaries of long documents, adding icons to headings and links are all examples of extra help and support. See the design requirments for support.
Feedback is usable by everyone. If users have difficulty sending feedback then you will not know if they are able to use the content or when they are experiencing problems. Therefore, it is essential that all the feedback mechanisms are tested by people with cognitive disabilities. See the design requirments for feedback.
The task force is taking all the design requirements and turning them into easy to read checkpoints. They will be divided by themes listed above. Most of the design requirements were originally created as recommendations for WCAG, the full list of potential requirements is available, and you can also review the progress of the task force in making readable requirements geared to web developers. The task force appreciates feedback on this work.
The table of design requirements and user groups maps requirements such as "User safety" and "Task completion" with the groups of users who benefit, such as those with "Memory impairments" and "Reduced focus and context".
Please review the table at Table of design requirements and user groups
The task force intends to redo this table when the easy to read design recommendations are complete.
We intend to add sections on GPS systems, conversational interfaces. Design patterns and gathering and analyzing user feedback and data.
We intend to redo the introduction
This section provides guidance for policy makers on how to use the design requirements to build a policy. This includes:
Table of design requirements and policy criteria
| Number | Name | Testable | Requires user testing | Can be applied to all content | Important for conversational interfaces | Important for IOT | User need level |
|---|---|---|---|---|---|---|---|
| 1 | Clear purpose | yes | no | yes | yes | yes | high |
| 2 | Support personalization | yes | no | yes | yes | yes | high |
| 3 | Support simplification | yes | no | yes | yes | yes | high |
| 4 | Familiar design | yes | sometimes | yes | no | yes | high |
This table needs to be completed for each design requirement. The task force would appreciate feedback on additional criteria that would be helpful for policy makers.
Example recommendations for policies:
The following are example scenarios that may be included in a policy:
The following are example user considerations:
Other considerations include:
This section is incomplete. The task force would appreciate receiving feedback of such as additional examples, scenarios and considerations.
We intend to add a glossary and links to our research pages
This section will have a detailed design guide. We are considering publishing it as a separate document.
The themes are:
Design so that as many users as possible understand the site and know how to use it: See the design guide for understandable design.
Help the user find what they need: See the design guide for navigation.
Use clear and understandable content: See the design guide for understandable content.
Prevent the user from making mistakes and make it easy to correct mistakes when they do occur: See the design guide for errors.
Help the user focus and restore context if attention is lost: See the design guide for focus.
Minimize the cognitive skills required to use the content and avoid barriers: See the design guide for barriers.
Provide help and support: See the design guide for support.
Feedback is usable by everyone: See the design guide for feedback.
This section is non-normative.
This publication has been funded in part with Federal funds from the U.S. Department of Health and Human Services, National Institute on Disability Independent Living and Rehabilitation Research (NIDILRR) under contract HHSP23301500054. The content of this publication does not necessarily reflect the views or official policies of the U.S. Department of Health and Human Services, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.