Making content usable for people with cognitive and learning disabilities

W3C Editor's Draft

This version:
https://w3c.github.io/coga/content-usable/
Latest published version:
https://www.w3.org/TR/coga-usable/
Latest editor's draft:
https://w3c.github.io/coga/content-usable/
Editors:
(W3C)

Abstract

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.

Status of This Document

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 an Editor's Draft.

Comments regarding this document are welcome. Please send them to public-coga-comments@w3.org (archives).

Publication as an Editor's 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. 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.

1. Introduction

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.

2. 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)

3. Applicability across websites

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.

4. Background about people with learning and cognitive disabilities and the web

People with cognitive and learning disabilities may be unable to use web content because of the design choices of the author. Examples include:

5. User Needs

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.

  1. Authentication and Safety
    • secure website authentication that is easy to use
    • safe way to interact online.
  2. Context and Distractions
    • consume content or complete a task without unnecessary distractions
    • know the context (where I am, what I just did, or what just happened)
    • restore context
      • when I forget where I am or get distracted
      • in multimedia. ability to go back to what I just missed, or reorient myself if I get lost
    • reminders of important information
    • turn off distractions by default and be a trivial option in real time
  3. Entering Data, Error Prevention, & Recovery
    • help avoiding mistakes, and minimizing the mistakes I might make
    • know what mistake were made and how to correct a mistake. Do no cause undue alarm a mistake happens
    • enough time, and do not lose work
    • use applications or APIs that remember a lot of my information so I do not need to enter it again, and to otherwise help me, such as with spelling.
    • know where I am in a process, including what I have done and what my next step is.
    • able to check my work and go back without losing the work I have just done
  4. Help and support
    • more explanations, such as context sensitive help and short tips.
    • know how to get more information.
    • easily get human help.
    • symbols that help me understand content.
    • contextually-relevant graphs and pictures to supplement text so I can understand a point without a lot of reading.
    • speech support, with synchronized highlighting, so I can follow as I go.
    • rapid feedback.
    • highlight section of image, chart, or math, while the section is read.
    • more space between letters, words, sentences, and/or lines of text.
    • reminders, or I will forget appointments, and when I was meant to do things
    • not too many reminders, as I will be distracted.
    • confident that I can manage my tasks.
  5. Simple and Clear Interface
    • controls are clear
    • understand the menu terms so I know where to find things
    • find the controls that I need
    • a structure that is easy follow
    • can easily find content I need
    • signposts so I can find information I need
    • Multimedia - understandable structure. Easy to find the content needed
    • easily separate what I need, and do not need, and find what I need
    • know what an advertisement is, or one from a different website
    • know where to find things on a page
    • know the design patterns
    • unambiguous affordances - I know what things are and what they do
  6. Familiar Interface
    • familiar with the UI, and I know how to work it and what will happen when I work it
    • symbols I understand immediately
    • different types of messages to be consistent in different parts of the screen
    • controls to be consistently positioned on the screen
  7. Clear and understandable content and text.
    • clear language - Understandable use of vocabulary, syntax, and other aspects of language
    • clarify implied information and provide unambiguous information
    • reduction of dependence on understanding math concepts
    • support for slow readers
    • understand (familiar) symbols
    • understand images and multi-media
  8. Navigating the system
    • find information I need without deciphering a lot of words or symbols
    • quickly identify options I need.
    • simple-to-navigate menu systems
    • simple-to-navigate voice-menu systems
    • find a human help
  9. Navigation and GPS
    • option for simplicity - let me balance complexity and speed
    • understandable terms, which make sense to users, and do not depend on knowing left and right, or on number dependence
    • no automatic rerouting without user consent
    • understandable symbols
    • no change of context
    • no change to orientation
Editor's note

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

6. Use Cases / Persona

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.

Personas for learning and cognitive disabilities.

7. Usability Testing, Focus Groups and Feedback

Usability testing is the best way to know if your content and functionality works for real people with cognitive and learning disabilities.

aspects for providing guidance, include usability, accessibility, reliably testable accessibility and automatically testable accessibility

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:

7.1 Differences from usability testing with the general population

There are some differences when testing for accessibility, and that includes when testing with people who have cognitive impairments:

Editor's note

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:

  1. Can your users ( people with learning and cognitive disabilities) manage each task reasonably easily and fast. You can time the task taken to complete, and note any parts that where the users are slowed down or seem to struggle. Also note any errors that they making including clicking on the wrong thing.
  2. Is completing the task frustrating or upsetting?
    1. You can ask the users how they are feeling before and after the tasks (or rate their mode such as selecting the smilly which represents how they feel, such as:
    2. ask them if anything was annoying.
  3. How can you make it better for your users ( people with learning and cognitive disabilities)

    1. You can analyze the data collected above
    2. ask them how they feel about the system and if anything was annoying.

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

8. Design Themes

To help web content providers meet the needs of people with cognitive and learning disabilities we have identified the following themes:

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

  2. Help the user find what they need. Navigating the system should be easy. See the design requirments for navigation.

  3. Use clear and understandable content This includes clear text, clear images, speech, and easy to understand video. See the design requirments for understandable content.

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

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

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

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

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

Editor's note

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.

9. Mapping requirements to user groups

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

Editor's note

The task force intends to redo this table when the easy to read design recommendations are complete.

10. Special applications

We intend to add sections on GPS systems, conversational interfaces. Design patterns and gathering and analyzing user feedback and data.

11. Issues and considerations

Editor's note
We intend to add additional sections on:
  • Items for further research
  • Data driven systems
  • Known issues (internationalization, author burden, test ability)
  • Guidance for assistive technologies
  • Guidance for Browsers

11.1 Guidance for policy makers

Editor's note

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
Editor's note

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:

Editor's note

This section is incomplete. The task force would appreciate receiving feedback of such as additional examples, scenarios and considerations.

Editor's note

We intend to add a glossary and links to our research pages

A. Appendix - Guide Details

Editor's note

This section will have a detailed design guide. We are considering publishing it as a separate document.

The group is working on a design guide to help make Web Content more usable for people with cognitive and learning disabilities (COGA).The guide is divided into themes. There are also user stories and testing methodologies for each theme. Just understanding the themes and user stories may help 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 COGA user testing.

The themes are:

  1. Design so that as many users as possible understand the site and know how to use it: See the design guide for understandable design.

  2. Help the user find what they need: See the design guide for navigation.

  3. Use clear and understandable content: See the design guide for understandable content.

  4. Prevent the user from making mistakes and make it easy to correct mistakes when they do occur: See the design guide for errors.

  5. Help the user focus and restore context if attention is lost: See the design guide for focus.

  6. Minimize the cognitive skills required to use the content and avoid barriers: See the design guide for barriers.

  7. Provide help and support: See the design guide for support.

  8. Feedback is usable by everyone: See the design guide for feedback.

B. Acknowledgments

This section is non-normative.

B.1 Participants active in the Cognitive and Learning Disabilities Task Force at the time of publication

B.2 Other Cognitive and Learning Disabilities Task Force contributors, commenters, and previously active participants

B.3 Enabling funders

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.