Making Content For People With Cognitive and Learning Disabilities - Design Guide

W3C Editor's Draft

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

Abstract

This section is non-normative.

This document is 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.

If you are a person with a learning or cognitive challenge and have found other problems that we have not covered please let us know! You can email us with your comments and ideas at public-comments-wcag20@w3.org.

Editor's note
This document is an appendix for Making content usable for people with cognitive and learning disabilities. We are considering publishing it as a separate note.

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 Cognitive and Learning Disabilities Accessibility Task Force, 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 (Cognitive and Learning Disabilities Accessibility Task Force), 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.

This guide is divided into design themes. There are also user stories, testing methodologies, and design checkpoints 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.

Editor's note

EDITOR’S note: This is an early draft. We expect many editorial changes to make the content more clear and easy to understand. We will also change the format along the lines of https://www.w3.org/WAI/WCAG21/quickref/

2. Theme 1: Help users

To be able to use a site or application, people need to know what all controls and element are on your page and how to use them.

Not everyone finds learning new things easy, and not everyone can remember new designs.

The more people need to figure things out, the less people can use your site.

Many users cannot easily learn new design metaphors, or remember things they learned, such as users with mild cognitive impairment or dementia. Without these skills, it can be much harder or impossible to find what they need, work out what the items do and how to use them.

Many users can be overwhelmed by too many options, or too much information. If reading is slow, then too much information mixed together will make it difficult or impossible to use the site.

Using familiar design, familiar terms and familiar symbols are key to being able to use the web for users who will struggle to remember new symbols and design. Users need the following to be familiar:

The use of personalization can be extremely useful in offering both familiarity as well as other benefits for users with cognitive and learning disabilities. This is important as what is familiar for one user may not be familiar to another. Familiarity is often based on the needs of the individual user.

2.1 User testing - Does the understand what UI elements, their purpose, and utility?

Make sure your user testing has all the different cognitive disabilities represented. (Make sure people don't just ask these as questions, but ask something that demonstrates it.)

Test for the following:

2.2 Example user stories: Does the user understand what things are and know how to use them

This leads to the following user stories:

2.3 Design guidance: Does the user understand what things are and know how to use them

2.3.1 Make the purpose of your page clear

Use a clear title or heading that summarizes the purpose of a page, or other clear signposts that have been tested by users with cognitive disabilities.

2.3.1.1 How it helps

This helps many people, including those with poor memory, attention, or anyone who is easily distracted. This includes people with age-appropriate forgetfulness, or Attention-Deficit/Hyperactivity Disorder.

For example, someone with mild dementia is using online shopping. They get distracted and then when they look at the screen again they have forgotten what they were doing. Put a clear heading at the top of each page that shows clearly what the page is about and what they are doing.

2.3.1.2 More details

Heading need to clarify the purpose of this specific page

2.3.1.3 Examples

Success example: Headings tell me exactly where I am

Failure example: Heading that doesn't clarify the step in a form

Todo: add this example

Failure example: Service not available…. what service?

I have to remember what I was doing to know what service this is about.

2.3.1.4 Technical Resources and History:

More technical details and testable wording proposals are available at:

coga github: clear purpose

WCAG issue 55

Pull request

2.3.2 Make each step clear

Use signposts such as breadcrumbs in tasks with a few steps. Breadcrumbs should include, steps completed, current step and steps pending.

Editor's note

Editor's note: This design requirement needs more work. This may include:

  • Making it easier to understand
  • Fitting it to our template
  • Adding more information
2.3.2.1 Examples

Success example: Breadcrumbs tell me exactly where I am

2.3.3 Headings, visual hierarchies and white space

  • Use clear headings
  • Items of related content grouped together
  • Lack of clutter and use of white space
2.3.3.1 How It Helps

There is a need for clear visual hierarchies with headings and subheadings and content that is related being grouped with sufficient white or negative space to clarify the fact that it has a different meaning from other content.

“If a user is comfortable, not hindered by clutter and superfluous words, and can scan the main points, he will get the summary of the article quickly and easily.”(Coyne, 2007)

However, users tend not to recall more than one or two highlighted items. White space around the highlighted items can increase their prominence (Olsen, 2002) and make content more readable.

A study (Lin, 2004) found that good use of white space between paragraphs and in the left and right margins increases comprehension by almost 20%. Readers find it easier to focus on and process generously spaced content.

2.3.3.2 Examples

Success Examples

https://www.barclays.co.uk/current-accounts/student-account/

https://www.gov.uk/benefits-calculators

https://www.ageuk.org.uk/information-advice/care/paying-for-care/paying-for-homecare/

Interesting design and responsivehttps://www.mencap.org.uk/learning-disability-explained/research-and-statistics/how-common-learning-disability

2.3.3.3 Technical References

Proposed: Lack of clutter and use of white space

1.4.8 Visual Presentation:For the visual presentation of blocks of text and objects, a mechanism is available to achieve the following (Level AA):

Increased line and border spacing can be added around blocks of text and objects, such that they can be increased up to 200% without loss of content or functionality.Include:

https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html

2.3.4 Use white space and call out boxes

On different types of content use

  • Consistent cues are provided that identifies different content types and the status of elements and regions that help the user understand its role.
  • Provide symbols that help the user identify key
  • Bold keywords to identify key topics
Editor's note

Editor's note: This design requirement needs more work. This may include:

  • Making it easier to understand
  • Fitting it to our template
  • Adding more information

See https://rawgit.com/w3c/coga/master/extension/help.html

2.3.4.1 Details

For key content and call out boxes

  • Consistent cues are provided that identifies different content types and the status of elements and regions that help the user understand its role or state.
  • Provide symbols that help the user identify key content including:
    • types of contact information
    • types of help
    • types of functions
    • warnings
    • key points
    • errors
    • system messages
    • notes
    • definitions
    • more information
    • tables of content and site maps
    • file types
    • search
    • required information
    • opinions
    • essential information
    • types of transaction and type of reminder
    • instructions and status of an element
    • invalid fields
    • non-native
    • content and sponsored content are clearly marked and visually differentiated by standardized techniques

2.3.5 Chunk Media

Long pieces of media should be divided into logical segments.

Allow person to find and review a specific topic so that if they lose concentration during a segment, it is easy to restart that segment.

2.3.5.1 More details
  • Six minutes or fewer: Media should typically be divided into segments that are 6 minutes or fewer in duration.
  • Programmatically-determinable and logical: Media must be presented in a programmatically-determinable and logical order.
  • Navigable: Navigation to each segment, and a unique, descriptive label must be provided for each media segment.
Editor's note

Editor's note: This design requirement needs more work. This may include:

  • Making it easier to understand
  • Fitting it to our template
  • Adding more information

2.3.6 Make the purpose of each section clear

Editor's note

Editor's note: This design requirement needs more work. This may include:

  • Making it easier to understand
  • Fitting it to our template
  • Adding more information
  • (Technical details: coga github: clear purpose. WCAG issue 55. Pull request and Use headings (Technical details: On coga github: section-headings.html wcag issue 40 (Include: using section headings, make it clear what is the navigation bar)

    2.3.7 Make it clear what are controls and how they should be used

    Use a clear design for controls by:

    • Using a common style on controls (for example: links being underlined)
    • Using common design pattern on links and controls (for example: clicking on a link takes you to the page)
    • Make all the borders of controls clear other than textual links (for example: a help icon has a border)

    When this is not possible, provide instructions that explain their use. Instructions should be on the same page or one click away and written in plain language.

    2.3.7.1 How It Helps

    Using common style and design pattern on controls makes it easier to recognise and understand how to use it. Controls are parts of web pages that do something, e.g. a link, button, checkbox. The goal of these controls is to have someone use them.

    Some users have trouble when controls have a different look, color or shape than they have used before. For example, when links do not have underlines and blue or purple text (even if this appears with focus) some users will not know there is a link.

    If you have difficulty with memory, it can be harder to use unique controls. It may be slower to find them on the page. And even if they work just a little differently than similar ones, some may need to relearn how to use them each time they need to use them.

    Using typical controls on the page will help people know how to use them. When using more unique controls, include easy to follow instructions and make them easy to find. Regardless of how a user uses the page (vision, auditory, voice input) it should be easy to identify, understand and use the controls.

    If you are designing a new control, make them easy to identify (I know they are there), understand (I know what they do), and use (I know how to use them). Test with people with different cognitive and learning disabilities. Use a simple style or have easy to follow instructions that explain their use.

    2.3.7.2 Examples

    Good Examples:

    Links with an underline and/or blue text color (or purple for already visited links), or both clearly identify links. Once a color is selected to be the primary link text color, other text on the page does not use this.

    In the example below, the links have an underline and are blue, or they are blue. There is no text that is blue that is not a link.

    Poor Examples

    Links without an underline or usual blue text color (or purple for already visited links), even those that become clear when they receive focus are more difficult to use. Some users may not know they are there.

    In the example below, the links do not have an underline, and they are not blue. Also, this page lacks a consistent link text color so easy to follow instructions would not be helpful.

    The black rectangles are around text that is a link, some of which has green text, others with black. The red circles are around green text which is not a link.

    2.3.7.3 Technical Resources and History

    Questions raised in the github discussion:

    • Defining controls
    • 2.4.4 Link purpose. "The purpose of each link can be determined from the link text alone or..."
      • Difference: how do I know it is a link?
        • E.g. can I ask all links to be underlined and blue if this is not their automatic state?
        • I know something is a link because:
          • Underlined and blue (or purple if a visited link) – if I have vision
          • Announces as link – if using text to speech tool
          • Cursor change
    • 3.2.4 Consistent Identification. Components that have the same functionality within a set of content are identified consistently.
      • If unusual, even if consistent, this does not make it easy to identify
    • 3.2.2 Labels or instructions are provided when content requires user input.
      • If style selected requires instructions, slows down person using them.

    2.3.8 Each region and its controls can be clearly recognized

    Make the relationship between different parts of the page clear by:

    • Use clear dividers between different sections in a page that may have separate controls or a scroll bar
    • Use clear dividers around areas in a page with different functions, such as call out boxes, navigation bars, and advertisements.

    Avoiding multiple scrolling areas/regions in a page will also help.

    2.3.8.1 More details
    • Examples of clear dividers include high contrast borders or white space. A change in background color can be a clear divider if the contrast is strong enough.
    • Sometimes the structure and relationships can be made clear through personalization or user agents and good use of semantics in the code (see WCAG 2.0 SC 1.3.1).
    2.3.8.2 How it helps

    Controls that affect only one section of a page can be confusing. Having a border around the controls and the relevant page section is helpful. If the controls cannot be next to the area they affect, check with user testing that the users find all the page relationships clear and immediately know how to use the controls.

    For example, consider someone with dementia trying to work out which scrollbar to use if there are more than one embedded in scrollable regions. When users try the wrong scrollbar, they do not get the effect they desire. Many users will look again at the content, try and work out what they are supposed to do, and discover the correct scrollbar. However, many people with cognitive disabilities will not be able to work out what they did incorrectly. Others will feel cognitive overload, and will give up before they try. They may assume the application is broken, or that it is just too complicated for them. For all of these users, the application will not be usable.

    2.3.8.3 Examples

    Failures Examples

    • When scrollbars are embedded in scrollable regions, and it is unclear which scrollbar to use.
    • The search box relates to one area of a page, and not for another area. It is unclear which area the search is for.
    • Controls act on one region and t is not clear which areas are acted on.

    Pass Examples

    GOV.UK

    2.3.8.4 Technical References

    On coga github: clear-structure-and-relationships.html

    wcag issue 26

    2.3.9 Toolbars and controls are visible or easy to find

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information

    Toolbars and controls do not disappear.

    2.3.9.1 Technical References

    On coga github: clear-structure-and-relationships.html

    wcag issue 26 and wcag issue 39

    2.3.11 Support personalization of symbols and controls

    Allow the look of symbols and controls to change for different users. Adding semantics on what each symbol and control allows the browser or extensions to change the look of the content. It also allows applications to add support that is appropriate for each user.

    For example:

    • Use aui-action on buttons
    • Use aui-symbol on icons
    • Use aui-destination on links
    • Use aui-field or HTML autocorrect on fields
    • Use aui-simplification on regions and controls
    • Use other attributes in personalization semantics
    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    2.3.11.1 More details
    • Test your page with user profiles with different icons to check that the personalization is working.
    • You can also provide a link where necessary to supporting user agent or have a personalization options tool bar on your page.
    Editor's note

    Editor's note: Personalization technology is still young. At the of publication HTML autocorrect on fields was the best supported.

    2.3.11.2 How it helps

    Personalization changes the interface to meet the needs of the user.

    Having familiar terms and symbols is key to many users being able to use the web. However, what is familiar for one user may be unfamiliar to another requiring them to learn new symbols. Adding semantics allow symbols and support to be added by an extension or browser that is familiar to the individual user.

    A stronger example is people using Alternative and Augmentative Communication (AAC) systems. AAC systems designed for people who are non-verbal often use symbols with or without text.

    These users usually only learn one symbol set. They cannot easily communicate with other symbol users in a written format or may struggle to understand different symbols used in different applications. Some symbols are subject to copyright and cannot be shared across applications.

    If users' symbols are mapped to the same concepts, then user agents can load the symbols that are understandable by the user and they user can access the web and other applications.

    Other support include autocomplete and extension that help the user fill out forms and understand the content.

    2.3.11.3 Examples

    Success examples

    Example taken from adaptable ui personalisation.

    aui-action="compose"

    A page working with autocorrect

    Examples of working pages can be found Implementations of Semantics, also see Getting started with personalization semantics

    2.3.11.4 Technical References

    On coga github: support-personalization.html

    wcag issue 6

    2.3.12 Support simplification

    Allow the user to remove features that most users do not need most of the time. Typically a simple application has 3 to 6 functions.

    For example:

    • Use aui-simplification on regions and controls
    • Use other attributes in personalization semantics
    • Add a simplification toolbar
    • Provide an alternative version
    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information

    2.3.13 Use a design that the user is likely to recognise and understand

    A familiar design includes:

    • Links look like links and buttons look and act like buttons
      • For example, underline links with a standard style throughout
      • User interface (design) from a prior version: Allow users to revert back to a prior version of the application that they are familiar with.
    • Uses common design patterns, such as are documented in the ARIA authoring best practices or are used in the most popular sites
      • Very common navigation design patterns and common icons.
      • A platform specific user interface design for navigation mechanisms and icons
      • An adaptive user interface design that can be personalized (see above).
    • Create a standard Visual Hierarchy - Place elements where the user is expecting them, such as
      • putting the search in the top left hand corner in a website
      • The link to the home page is in the top right hand corner
      • Link to ‘contact us’ is in the top navigation
      • Link to the site map is in the footer area
      • Submit button is at the bottom right for a form

    Note that these examples will be different in non-left to right languages

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    • Getting rid of overlap
    2.3.13.1 How it helps

    Many people cannot easily learn new design metaphors or remember things that they have learned for example, people with Mild Cognitive Impairment (MCI) or dementia. Without these skills it can be much harder or impossible to:

    • Locate desired items to interact with
    • Know what the interaction will do

    Using familiar design, terms and symbols is key to being able to use the Web for people who cannot remember new symbols for example, some people with memory related impairments like dementia.

    For example, a user may have used an email program for the last few years. Now the interface has been updated and with these changes the user needs to learn new icons, and navigation. If the user is learning impaired or has their memory has become less good as they aged they may not able to learn the new navigation. This may keep them from reaching and using the content. Letting the user keep the old navigation, interface and icons helps them continue using the content.

    2.3.13.2 Failures

    Items that act like a button but are not instantly recognizable as a button. Links that are not instantly recognizable as links

    Can you see the scroll bar in the bellow picture?

    2.3.13.3 Passes
    • Use standard Web layout design, so it is easy to find common content. In 2015 in English sites this includes:
      • The search box is in the right hand corner
      • A link to home page in the left hand corner
      • The site map in the footer
      • Main menus are at the top of the page under the log and search or on the left hand side
      • Links are underlined
      • Using common icons:
        • Icons used in a standard or common operating system.
        • A question mark for help
        • An exclamation mark for warnings
    • For iOS on each screen UI Bars, UI Views and UI Controls align with iOS Human Interface Guidelines

    See also

    2.3.13.4 Technical details

    On coga github: familiar-design-a.html

    wcag issue 49, pull request

    On coga github: familiar-design-aa.html

    wcag issue 35

    2.3.14 Use a consistent look

    This includes:

    • Headings with the same level and role have the same style.
    • Icons Controls and menu items that have same function and role have the same look and style
    • State changes and focus changes for similar functionality and roles have the same style are used consistently across a site.
    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    • Getting rid of overlap
    2.3.14.1 More details

    The more predictable the content, the easier it is to know how to use it. Many users with neurological or intellectual and learning disabilities rely heavily on their familiarity with a web pages’ components. They may learn a specific interface. If identical functions are presented differently on different web pages, the site will be considerably more difficult to use. It will also be confusing, and increase the cognitive load for people with cognitive disabilities, limiting some users from accessing the content.

    Note that if there is a different background or context, the look and color scheme may need to change. However, try to keep a similar look and feel.

    For example, someone who finds it hard to learn new interfaces may need guidance to use the first page of you application. If the second page is different supportive cues should be introduced.

    This helps people with reading and visual-perceptual difficulties which could be due to Receptive Aphasia and acquired dyslexia resulting from a stroke; as well as those with general cognitive learning disabilities. It also helps those with visual-acuity difficulties and users with poor memory where clarity of information and imagery is very important. Consistent styles helps everyone and will increase the number of people who can use the site.

    2.3.14.2 Passes

    CSS is used consistently on headings, roles, personalization, and semantics.

    2.3.14.3 Failure

    Headings vary in style, menu items vary in function and buttons look different when pressed. Graphic package required with the following items: consistent headings, control appearance & icons consistency.

    Additional Resources:

    <
    2.3.14.4 Technical details

    On coga github: consistent-identification-and-styles.html, wcag issue 28, On coga github: consistent-cues.html, wcag issue 31 and wcag pull request 108

    2.3.15 Make a consistent page structure

    Use a consistent position of common navigation, search, and control elements.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    • Getting rid of overlap
    2.3.15.1 How it helps

    Changing the position of elements and design will be confusing. It increases what the user needs to learn to use the content. It will increase the cognitive load for people with cognitive disabilities, increasing mistakes, and limiting some users from accessing the content.

    Additional Resources:

    2.3.15.2 Technical details:

    On coga github: consistent-navigation.html and wcag issue 29.

    2.3.16 Use symbols that help the user

    Use symbols

    • Use clear symbols that can easily be seen and expanded
    • Use images understood by different users
    • In left-to-right languages, place the image to the left of the text
    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    2.3.16.1 How it helps

    The benefit of this to people who find reading or language difficult cannot be underestimated. This population may include people who have developmental delays or acquired or progressive brain damage. For example, a person with severe aphasia, where they have the intellectual ability to understand concepts, but cannot express those concepts, read text or write the word needed in a search field, is dependent on the use of symbols to browse pages for information.

    It can also help the elderly population who can find cluttered pages with dense text hard to read on a screen. Clear symbols and images that act as signposts to the text content can be very helpful.

    Graphic package required with the following items: consistent headings, control appearance & icons consistency.

    Additional Resources:

    2.3.16.2 Technical details

    On coga github: extra-symbols.html and wcag issue 50PR # 115.

    3. Theme 2: Help the user find what they need

    3.1 Design guidance: Help the user find what they need

    3.1.1 Make it easy to find help.

    Help content, support page or support function is available to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls. When human help is available the correct contact information or help is reachable within one user action for voice menus and in other modalities at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.

    3.1.1.1 How It Helps

    When a person does not understand how to use a website effectively, they try to access the help content. Users who need help content are usually already confused. Help content, support pages, and support functions should be clear and easy to find, and easily reachable when they need to use them.

    Human help includes:

    • Live help option. Note: It must be easy and clear to close the window.
    • A phone number that will automatically call via an interoperable Voice over IP specification.
    • A simple contact us form

    Use available standards to get human help such as using the 0 digit on voice menu systems.

    Putting help information in the header, footer, or on a specific webpage may cause more challenges for users that are already frustrated because these locations may be difficult to find or use.

    3.1.1.2 Examples

    Good Examples: University of Minnesota Libraries

    The University of Minnesota Libraries site lets the user easily choose to either access help pages or chat with a person. The white square is around the help drop down, and the black circle around the 24/7 Chat button.

    Poor example:

    Sites that do not have a “help” link or menu, Contact Us, or phone number and email address on their home page.

    3.1.1.3 Technical Details

    On coga github: finding-help.html

    wcag issue 43

    3.1.2 Make it easy to find the most important things on the page

    Critical features and important information are above the fold and are accentuated.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    3.1.2.1 How it helps

    Users who do not remember to use the scroll will be able to use critical features.

    When the main features are under the fold, these users will be unable to complete the main task. Therefore, designers should either have critical features above the fold or have a clearly labeled mechanism to help users find critical feature (such as a menu button).

    This can also be achieved via personalization

    For example, in an application for drafting an email, the send button is a critical feature without which the application has no use. The author must put any critical features, such as send, above the fold.

    See the section on testability for additional clarity.

    People with low executive function, impaired memory, and other cognitive and learning disabilities may not be able to find features that are under the fold and that require the use of the scroll bar.

    Many users are happy with important features being "discoverable" where they have to figure out or learn how to use them. The interface becomes a problem to solve. However people with some cognitive and learning disabilities may lack the executive function to figure this out, and people with impaired memory may not remember to use the scroll as a mechanism for finding content.

    3.1.2.2 Technical details

    On coga github: critical-features.html and wcag issue 39

    3.1.3 Use a clear navigation

    Use clear text and design. Less than 7 elements on the main navigation. If you use a secondary navigation make sure it is not standing out as much as the main navigation.

    A familiar layout of navigational elements and common icons are easily available such as: the standard for the user platform or, a previous versions of this product that the user is familiar with and has successfully used.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    3.1.3.1 How it helps

    The intent is to help 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. As many users, for example, people with memory impairments such as dementia, cannot learn new designs, this is essential for them to be able to use the content. Personalization and good use of semantics can help make symbols and design as familiar to the user as possible.

    Many people cannot easily learn new design metaphors or remember things that they have learned for example, people with Mild Cognitive Impairment (MCI) or dementia. Without these skills it can be much harder or impossible to:

    • Locate desired items to interact with
    • Know what the interaction will do

    Using familiar design, terms and symbols is key to being able to use the Web for people who cannot remember new symbols for example, some people with memory related impairments like dementia. Therefore this design requirement addresses the user need for things to be familiar including:

    • Location of elements
    • Symbols

    Note: Familiar text is addressed in another requirement.

    An adaptive user interface design which changes based on user preferences allows users with a variety of cognitive disabilities to adjust an interface based on their specific needs. Various platforms may offer guidance for creating user interface designs. Following such guidelines helps to create consistency not only within a single application but across multiple applications. These guidelines reinforce consistency which is known to have a positive impact on users with a variety of cognitive disabilities.

    It should be noted that the task force has worked to show the viability of easy personalization with:

    • Easy to tailor symbols, user interface for user profiles
    • Easy to get help that works for this user profile
    • General help and context sensitive help

    JSON is being used for collections of name/value pairs for each skin.

    We are also standardizing the relevant semantics and personalization settings to support alternative implementations.

    Consistent navigational cues benefit all web users, providing clear, effective and efficient way finding. It has particular benefit for those who have cognitive impairments, which may have an impact on memory, visual and auditory perception and comprehension. These users should not be faced with barriers such as complex abstract imagery or ambiguous navigational elements

    For example, a user may have used an email program for the last few years. Now the interface has been updated and with these changes the user needs to learn new icons, and navigation. If the user is learning impaired or has an impaired memory and is not able to learn the new navigation this may keep them from reaching and using the content.

    As one user with mild dementia stated "I have great difficulty remembering things, working things out, and interpreting things."

    As long as interfaces are familiar the user can continue to use the Web.

    Using common icons in the expected position help. But, because what is familiar to one person may not be familiar to another person enabling personalization of icons is the most useful approach.

    3.1.3.2 Technical details

    On coga github: familiar-design-aa.html

    wcag issue 35

    3.1.5 Avoid scroll

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    3.1.5.1 How it helps
    • Add pages and better highercal design
    • Including critical content at the top of the page, so users don't have to scroll down to understand the content and context of the page.

    For people with learning and cognitive disabilities being unable to view all content in its entirety means that the purpose the content cannot be interpreted as a whole, whilst creating an unnecessary cognitive load on the user to remember previous content.

    3.1.6 Always let the user go back

    Let the user return to a previous point without undoing their work.

    The standard back button is the best way to do this as it is familiar to the user and this might be the way they will try first. The user should never lose their work if they try pressing back.

    3.1.6.1 How it helps

    This helps prevent users from making mistakes and makes it easy to correct mistakes when they happen.

    Examples of mistakes include:

    • touching a control by accident,
    • opening a new link by accident,
    • closing a window that you intended to keep open.

    If a person easily makes mistakes or makes them often, it is important that they can go back and make changes without having their work or previous choices deleted.

    In forms, each time the user has to re-enter data there is a new chance for mistakes to occur. Entering and re-entering data can be stressful and tiring from some people with learning andcognitive disabilities. This increases the likelihood of mistakes and may make it impossible to submit correct data and complete the intended task.

    For those with anxiety, memory challenges, and difficulty following directions, the ability to go back and review information they have entered is very important. For example, for some people the task of following directions and reviewing their answers works best as two separate tasks. Being able to enter information with their focus being on following the directions, and later going back to review their answers, helps them be more effective.

    When the user has an opportunity to go back and review the data they entered, even ifsubmitted by mistake, it is easier to correct the information.

    3.1.6.2 More details
    • A user can go back steps in a user journey via a clearly labelled action.
    • Clickable breadcrumbs are provided with clickable previous steps and no loss of data.
    • Providing back and undo features without unwanted data loss.
    • Using semantics and personalization to log the steps and return to a step in the process.
    • A user can go back to a closed window or option.
    3.1.6.3 Examples

    Success example:

    Completing an online form when applying for a job. The user is able to go back through all the screens to be sure they did not misunderstand a section, skip an answer, and can edit any data they mistyped.

    Failure example:

    Completing an online form when applying for a job. The user goes back a screen because they realize they may have forgotten to answer a question. When they use the back button all data previously entered has been cleared/deleted.

    3.1.6.4 Technical details

    The following are proposals for WCAG. They experiment with more testable language:wacg issue 38 and >wacg issue 53

    This is not to be used if going back may cause a security issue.

    This is different from 3.3.6 because 3.3.6 is AAA level but this is a need for a wide variety of users (more of an A or AA level requirement). Also, 3.3.6 refers to reviewing and confirming capabilities, but it does not address the concept of an entire form - it can be interpreted to mean a single form control. The challenge for those with learning and cognitive disabilities may increase when multiple form controls or entries are required together. For example, a job application, government services application, etc. Different types of information (data like number identifiers) mixed with short or long paragraph information, mixed with “if this” then “enter this” directions. The more complex and long the data to be entered, the more an individual may need to be able to go back and review multiple entries, not just one at a time.

    Graphic package required with the following items: Breadcrumbs, undo button/link

    Additional Resources:

    4. Theme 3: Use clear and understandable content and text

    Note that a lot can be achieved through supporting personalization.

    4.1 Example user stories: Use clear and understandable content and text

    User needs for understandable text:

    4.2 Design guidance: Is the content the clear and understandable?

    4.2.1 Use clear words

    • Use common and clear words. 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 make a new terms make sure the user has access to an explanation within one click or event.
    4.2.1.1 Getting started

    Start by putting clear words on headings labels, navigational elements, instructions, and error messages. This will increase the usability a lot without taking so long.

    4.2.1.2 How it helps

    This benefits many people including those with language impairments, learning disabilities or a poor memory.

    For example, someone with mild dementia is trying to turn on an ICT heating and air conditioning unit. The menu item for selecting heat or air conditioning is labeled "mode". The user cannot use the whole unit because of this one term. This has caused emergencies such as hypothermia.

    4.2.1.3 More details

    When different people find different abbreviations or terms easier to understand:

    • Add an simple language term in brackets next to it
    • As a pop up definition
    • In supported mark up (see easylang)
    4.2.1.4 Examples

    Success example: Plain text with clear words and definition of term.

    Your landlord must follow the law.

    • Your landlord can only use your security deposit (promise money), only for certain things, such as unpaid rent (rent that you owe) and to fix things that you damaged.
    • Your landlord must return your security deposit (promise money) to you by a clear date. This is usually 30 days after you leave the apartment.

    Failure example: Not plain text

    A Landlord's Right to Deduct. When a tenant moves into a rental property, he or she will pay the landlord a security deposit. Depending on the jurisdiction, this deposit will be returned to the tenant within a specific time period at the cessation of the lease term, as long as the tenant follows all the terms and tenants of the lease agreement or contract. Select links below to read the laws that pertain to your situation.

    Failure example: Using new words

    Note this could be a success example if a tooltip explained what raw and blame means (in simple language).

    4.2.1.5 Technical details

    Proposals for wcag design requirement can be found at On coga github: plain-language-a.html, wcag issue 30, pull request 135

    On coga github: plain-language-aa.html wcag issue 41, pull request 107

    On coga github: plain-language-aaa.htmlpull request 105.

    4.2.2 Use a simple tense and voicing

    Use the tense and the voice is easiest to understand. In English this is usually the present tense and active voice. Speak directly to the user, and use the simplest form of verbs.

    Active voice makes it clear who is supposed to do what. For example “It must be done.” (passive voice) does not say who has to do what. “You must do it.” is active voice and is more clear.

    4.2.2.1 How it helps

    This benefits many people including those with language impairments, learning disabilities or a poor memory. For example, more people will understand “press the on button” (present tense and active voice) then “the on button should be pressed”.

    4.2.2.2 More details
    • Other voices or tenses can be used when it has been shown to be easier to understand or friendlier.
    • In languages where present tense and active voice do not exist, or are not clearer, use the tense and the voice that are easiest to understand.
    • If you are writing about past or future events, do not use the present tense. It will just be confusing.
    4.2.2.3 Examples

    Success example: Plain text with definition of terms.

    Examples

    Success example: Plain text with clear words and definition of term.

    Your landlord must follow the law.

    • Your landlord can only use your security deposit (promise money), only for certain things, such as unpaid rent (rent that you owe) and to fix things that you damaged.
    • Your landlord must return your security deposit (promise money) to you by a clear date. This is usually 30 days after you leave the apartment.

    Failure example: Not plain text

    A Landlord's Right to Deduct. When a tenant moves into a rental property, he or she will pay the landlord a security deposit. Depending on the jurisdiction, this deposit will be returned to the tenant within a specific time period at the cessation of the lease term, as long as the tenant follows all the terms and tenants of the lease agreement or contract. Select links below to read the laws that pertain to your situation.

    4.2.2.4 Technical details

    Proposals for wcag design requirement can be found at On coga github: plain-language-a.html, wcag issue 30, pull request 135

    On coga github: plain-language-aa.html wcag issue 41, pull request 107

    On coga github: plain-language-aaa.htmlpull request 105.

    4.2.3 Do not use double negatives or clauses inside clauses

    Use a simple sentence structure. Do not use a double negative to express a positive. Do not use clauses inside clauses that can be confusing.

    For example, more people will understand “You must get the agency’s approval before we can answer your claim”: rather than “No approval of any claims can be achieved without the agency’s approval”.

    4.2.3.1 How it helps

    This benefits many people including those with language impairments, learning disabilities or a poor memory. For example, a person with early stage dementia can manage their own appointments and affairs because the language is clear and understandable.

    4.2.3.2 Examples

    Success Example

    “You must get the agency’s approval before we can answer your claim”

    Failure Example

    “No approval of any claims can be achieved without the agency’s approval”

    4.2.3.3 Technical details

    Proposals for wcag design requirement can be found at On coga github: plain-language-a.html, wcag issue 30, pull request 135

    On coga github: plain-language-aa.html wcag issue 41, pull request 107

    On coga github: plain-language-aaa.htmlpull request 105.

    4.2.4 Use literal language:

    Use literal and concrete language. When possible, use concrete terms and examples that refer to objects or events that you can see, hear or touch.

    Metaphors and similes should not be used unless they are explained. You can explain any non literal language:

    • In simple language in brackets next to any non-literal text (such as a Metaphors and similes)
    • As a pop up definition
    • In supported mark up (see aui-literal)
    4.2.4.1 How it helps

    Many people do not understand non literal content. For example, a programmer with autism spectrum disorder may not understand jokes and similes. Sometime instructions have jokes and similes to make their content more friendly. However this confuses the programmer who now can not do her job as needed.

    4.2.4.2 Getting started

    Start by putting clear literal text on headings, labels, navigational elements, instructions, error messages and any content that may affect the user’s rights or wellbeing. This will increase the usability in critical places without changing your writing style.

    4.2.4.3 More details

    The meaning must still be completely clear when non literal text is replaced by literal text. This needs to check when literal text provided in a popup or other alternative.

    4.2.4.4 Example

    Success example: literal text and concrete language

    If you are experiencing anxiety before starting take a deep breath, tell yourself you can do it and get started. Anxiety can include nervousness, fear, dizziness or shortness of breath.

    Success example: non-literal text

    If you are experiencing cold feet before starting take a deep breath and jump in.

    4.2.4.5 Technical details

    Proposals for wcag design requirement can be found at On coga github: plain-language-a.html, wcag issue 30, pull request 135

    On coga github: plain-language-aa.html wcag issue 41, pull request 107

    On coga github: plain-language-aaa.htmlpull request 105.

    4.2.5 Separate each instruction

    In Instructions, separate each step. It makes it much easier to follow.

    • Using numbers and lists can also help
    • Sometimes complex instructions can be easier to follow in an If/Then table
    • Using a friendly graphics can help make instructions less scary
    4.2.5.1 How it helps

    This benefits many people including those with language impairments, learning disabilities or a poor memory.

    For example, a person with a low working memory can not hold onto many pieces of information at the same time. If they need to remember what they are doing, divide the steps and track what they have done they are much more likely to make mistakes. When instructions are clearly separated and clearly laid they can follow them without making mistakes.

    4.2.5.2 Examples

    Success example: separate each step - IF/Then Table

    If Then
    If you want to work in programing
    • Make a resume
    • Get some sample code that you wrote
    • Send them to programing@example.com.
    If you want to work in design
    • Make a resume
    • Get some sample pages that you designed
    • Send them to design@examle.com.

    Failure example: separate each step

    If you want to work in programing, write to programing@example.com with a resume and sample code that you wrote. If you want to work in design write to design@examle.com with a resume and sample pages.

    4.2.5.3 Technical details

    Proposals for wcag design requirement can be found at On coga github: plain-language-a.html, wcag issue 30, pull request 135

    On coga github: plain-language-aa.html wcag issue 41, pull request 107

    On coga github: plain-language-aaa.htmlpull request 105.

    4.2.6 Keep text succinct

    • Keep paragraphs short. Have only one topic in each paragraph.
    • Use short sentences. Have only one point per sentence.
    • Use bulleted or numbered lists.
    • Use bullets or numbered lists
    4.2.6.1 How It Helps

    Chunking text content makes it easier to read and understand. People with poor memory or anyone who is easily distracted will benefit too. This also helps people with learning disabilities related to processing speed or language. Chunking is helpful to anyone who is multitasking.

    Example: a graduate student with ADD may need to teach themselves a new software skill. The software documentation is broken up into short paragraphs and lists by topic. The student finds the documentation easy to read and understand.

    4.2.6.2 More Details
    • What is a short paragraph? In English, if you have a paragraph of more than 50 words, see if it could be broken up into two paragraphs.
    • How can I avoid writing a sentence with more than one point? Sentences that have more than one point usually have more than one linking word such as ‘and’ or ‘but’.
    • Can a long sentence ever be clearer than two short sentences? Double-check if a long sentence is clearer than two short sentences. Do usability testing to see if people with cognitive disabilities find the long sentence easier to understand.
    • When should I use lists? Lists are great when you have three or more things in a row. Think about using an unordered list (with bullet points) for items, requirements, and exceptions. A series of three or more steps is easier to follow as a numbered list.
    4.2.6.3 Examples

    Success Example

    Calgary will have a lot of snow and hail this weekend. Try not to drive. If you must drive:

    • Use the rules for driving in winter to keep safe.
    • Before you leave, check what roads are safe at the Traveler’s Information Website.

    Failure Example

    DOTD Issues Winter Weather Travel Advisory for Calgary. With the possibility of snow and rain in the forecast throughout the holiday weekend, the Department of Transportation and Development (DOTD) announced that department staff is prepared to deal with winter weather. Maintenance forces will be on standby to apply sand and salt over any affected bridges and roadways, to remove fallen trees from the roadway, and to close any roads as needed. Interim Secretary Jane Doe urges motorists to take the threat of winter weather seriously. "In the event of adverse weather conditions, the department will strive to maintain access to highways and interstates; however, we encourage the motoring public to avoid traveling during snow and ice, if at all possible," said Doe. During winter weather conditions, the best thing motorists can do is drive slowly and carefully, and avoid driving while distracted. Always allow for extra driving time, reduce speeds when visibility is low, and make sure there is plenty of room between vehicles. Also, look out for black ice, which can form on bridges, overpasses, off- ramps and in shady spots. As always, DOTD reminds motorists to buckle up and refrain from drinking and driving. Citizens can get the latest updates on real-time traffic and road conditions by using the Traveler Information System simply by dialing ### from their telephone and saying the route or region about which they are seeking information. Travelers can also access this information by visiting the Traveler Information Website. Motorists can also obtain information regarding road closures by contacting DOTD’s Customer Service Center at (1-###-###-####). The center is open 7:30 a.m.- 5 p.m. Monday through Friday.

    4.2.6.4 Technical References

    4.2.7 Use clear spacing

    Allow for the ability to easily adjust white space around objects and text, including boxes, paragraph headings, and content, to a degree that suits the user and does not disrupt the overall integrity of a web page.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    4.2.7.1 How it helps

    White space, also described as negative space, reduces clutter and provides definition to content so that the viewer is given a clear overview of a web page. It is used by designers to enhance text and the position of objects on a page.

    Use of white space aids navigation through a page and improves readability. It can enhance tracking, where there is a considerable amount of text, and guides the user to important elements on a page. For those with cognitive impairments, it has been shown to ease reading difficulties and enable better comprehension of content.

    The capability to adjust the amount of white space around objects and text supports the ability to identify important elements in the content of a web page.

    4.2.7.2 Technical details

    Use clear spacing between letters, words , sentences lines, pargraphes and blocks of text. Text is not fully justified and On coga github: isual-presentation.html, wcag issue 51 and PR number 113.

    4.2.8 Use clear text and voice

    Provide clear typography (text and numbers), punctuation, and voice (speech) for readability and comprehension.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    4.2.8.1 How it helps

    Users should not need to spend extra cognitive function deciphering letters, numbers, and words, and can focus on understanding the meaning of the content. When words are hard to read or discriminate, users with language-related disabilities will fully focus on identifying the letters, and on building the words. They then have to piece together the words to build the sentence. However, there is a limit to how many cognitive tasks a person can do at the same time. If so much energy is put into identifying the words, it is often not possible to also understand the meaning of a sentence.

    This may be avoided by making the task of reading and identifying words easier, so that the user can focus on the meaning.

    If identifying words takes too much of a user's focus, the content will not be understood, making it not usable.

    Layout for Numbers

    Check use of white space and punctuation; and characters between numbers. Use of spaces and commas within numbers can change how text-to-speech engines read it. This confuses people with cognitive disabilities.

    Where any numbers are presented, their use needs to be considered. If they are representing dates, times, references, telephone numbers, or mathematical notation, their layout impacts on users' understanding. Users need not only to recognize standardized layouts, but also to understand the meaning as the numbers are read aloud by text-to-speech engines. This feature can provide those with dyscalculia, dyslexia, and attention deficit disorder, and those who may be under high-cognitive load or situationally disabled, with a better understanding of the concepts.

    4.2.8.2 Examples
    • Reference numbers compared to a quantity or a value, e.g., "Ref: 7241500", as opposed to "7,241,500 chickens".
    • Telephone numbers have localized layouts. Text-to-speech readers cope in different ways with the layout. Thus, a telephone symbol and/or a word for telephone/mobile/cell phone, alongside the number, can help avoid confusion.

    Roman Numerals

    Roman Numerals should be presented in upper case if used in isolation.Roman Numerals can be presented as lower case or upper case, especially when used with musical notation. However, these may not always be recognized by text-to-speech engines, or may be confused with other navigational elements, such as numerical bullet points. Use of Roman Numerals is not always easily understood. The use of this format for isolated numbers impacts on comprehension for those with dyscalculia, dyslexia, and attention deficit disorder, and should be avoided if possible.

    Example

    Text-to-speech engines will try to read the lower case Roman Numeral as a word, e.g., "vi" instead of "VI" - read as /vie/ instead of six.

    Pass example: Roman Numerals presented in upper case if used in isolation.

    Note that a blind person may also be dyslexic, or have a language disability.

    4.2.8.3 More details

    Exception: If a specific typography, punctuation, content (text or voice) is essential.

    4.2.8.4 Technical details

    On coga github: clear-text-and-voice.html

    wcag issue 27

    4.2.9 Provide summary of long documents

    Provide a brief summary for a long document and emphasize any import keywords to help people understand the purpose and contents of the document, and if it might contain information they need.

    Summaries should use common words, short sentences and be written in an easy to understand style and tense.

    4.2.9.1 How it helps

    Making the summary easy to understand helps many people to quickly decide if the document is relevant to them and their current goal. In this case, a very high level outline in a few sentences or bullet points is most effective. Abstracts and executive summaries are usually much longer and more detailed as they are designed to summarise the entire document.

    4.2.9.2 More details

    Long Documents have 300 words or more.

    In general headings are used to break the information down into a more manageable size and provide structure to the information being presented. This particularly benefits users of Assistive Technology. The first section should be a text summary of the document. It may include links to other sections if appropriate.

    Providing a text summary that can be understood by people with lower secondary education level reading ability. For pieces of content with less than 300 words the heading may act as an abstract.

    See the theme in understandable text for the minimum on how to write an understandable summary. User testing is recommended.

    4.2.9.3 Getting started
    4.2.9.4 Examples

    Success example from gov.uk

    Failure example:

    4.2.9.5 Technical details

    The following are proposals for WCAG. They experiment with more testable language

    On coga github: help.html

    wcag issue 32 and WCAG20-TECHS

    4.2.10 Use clear images

    Symbols are added at the beginning of short sentences and phrases to aid understanding. However, as some people have difficulty remembering symbols, use text with the symbol.

    • Use clear symbols that can easily be seen and expanded
    • Use images understood by different users
    • In left-to-right languages, place the image to the left of the text

    We are also drafting semantics that will add symbols that are easy to use by the individual user.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information

    See wcag issue 50

    4.2.11 Provide Alternatives for numbers

    Provide alternatives for numbers and numerical concepts

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    4.2.11.1 How it helps

    Not all people can understand numbers and numerical concepts.

    For example: A user with dyscalculia may have difficulty processing temperature data when presented only in a numeric format. However if non-numeric alternatives are provided (cold, warm, hot etc.) then the likelihood that they will have no issue in processing the data is high.

    See wcag issue 32

    5. Theme 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 easily without stess or extra steps.

    Completing forms and similar tasks is often overwhelming for most users with cognitive and learning disabilities. This includes relatively minor learning disabilities, such as Dyslexia, or attention related disabilities.

    Many users with learning disabilities cannot remember numbers, such as those for their post/zip code, Social Security, or credit card. Many users even need to check their phone numbers. This makes entering information slow, and they may need to leave their desks or take breaks.

    Also many users have short term memory issues that can make copying text difficult or impossible. For example, if you can remember 7 letters in your head at the same time. They may be able to remember one or two. This makes them much more likely to make mistakes copying as it requires you to remember the numbers or letter accurately.

    Note that a lot can be achieved through supporting personalization.

    5.1 User testing - Prevent the user from making mistakes and make it easy to correct mistakes when they do occur.

    Make sure your user testing has all the different cognitive disabilities represented. Test for the following:

    5.2 Example user stories: Prevent the user from making mistakes and make it easy to correct mistakes when they do occur.

    5.3 Design guidance: Prevent the user from making mistakes and make it easy to correct mistakes when they do occur.

    5.3.1 Build forms so that people make less mistakes

    Input errors should be automatic corrected (where the correction is reliable) if suggestions for corrections are known, the suggestions are provided to the user

    • In a text field, accept as many formats as possible. For example accept different formats of phone numbers and correct Input errors automatically
    • Use an interface were only valid input can be selected
    • Accept voice prompts for people with a speech impairment
    • Use the default format of the users location such as currency and temperature
    • Use autocomplete and personalization of form controls
    5.3.1.1 How it helps

    People with cognitive or learning disabilities and aging users often abandon tasks and believe they cannot complete them if they receive too many errors. Error messages may be confusing. Correcting errors is often difficult and frustrating for the user. Many users give up when they get successive errors

    For example, while registering for an online banking account a form requires the input of the user's birthdate. The required input format is xx/xx/xxxx with a leading zero for single digits. If a single input field with no input correction is presented, a user with a cognitive disability may enter 1/3/1996 thus triggering an error notification. It may not be clear to the user that the required format is 01/03/1996 even if an example for instance, xx/xx/xxxx, is shown below the input field or in the error notification.

    However a well designed form will make it easier to fill in the information and prevent the user from making mistakes.

    Image of options being restricted to valid inputs

    Autocomplete

    Minimizing user generated errors by automatically correcting them will also minimize error notifications. Error notifications may be distracting taking focus away from tasks and task completion.

    5.3.1.2 More details
    • Only correct errors if the correction is reliable. Otherwise, if suggestions for corrections are known, give the suggestions to the user.
      • for example “did you mean the first of February (01/02) or the second of January (02/01)
    • Calendars and dates
      • Calendars should default to the first relevant day. Work calendars should default to first working day of a user's locale.
      • Calendar based booking systems must avoid ability to book return date before departure date.
    • Temperature
    • Use the default temperature format of location.
    5.3.1.3 Examples

    Success Example:

    Autocomplete

    • Correct errors of the post code being written in the text field with the city or state information
    • User is unable to select inappropriate dates and a simple explanation provided should he/she try to do so.

    Failure Example:

    • Failure example: The booking form provides two calendars without clear labels and instruction and user is able to select dates without warning as to whether they are possible e.g. flight out on June 1st - flight return May 30th
    • Failure example: User can select inappropriate dates without warning. Calendar merely grays out inappropriate dates which may not be noticed. No warnings provided.
    5.3.1.4 Technical details

    The following are proposals for WCAG. They experiment with more testable language. coga on github: minimize-errors.html

    5.3.2 Help users find the content they can use

    Important information and features are above the fold and are clearly available in the main content area.

    5.3.2.1 How it helps

    People with low executive function, impaired memory, and other cognitive and learning disabilities may not be able to find features that are under the fold and that require the use of the scroll bar.

    For example, in an application for drafting an email the send button is a critical feature without which the application has no use. The author must put any critical features, such as send, above the fold.

    5.3.2.2 More details

    When the main features are below the fold some users will be unable to complete the main task. Critical features should be above the fold or have a clearly labeled mechanism to help users find them, such as a menu button.

    For websites which have a few clear tasks (such as an email provider) this requirement is important. For general information sites (such as news or government portals) it may not be possible to apply.

    5.3.2.3 Examples

    Success example: Critical features of an email application are above the fold.

    Failure example: Some critical features are out of the default view.

    5.3.2.4 Technical Resources and History

    More technical details and testable wording proposals are available at: WCAG 2.1 issue 39

    5.3.3 Make it easy to undo errors

    Allow the user to check their work before submitting a form so that they can correct any mistakes.Once they have fixed their mistake it should be easy to get back to the place they were at (without redoing extra steps).

    For financial transactions and important information: Allow the user to easily cancel the transactions and provide simple instructions including the amount of time the user has to cancel a transaction.

    5.3.3.1 How it helps

    People with cognitive and learning impairments make many more mistakes in filling out forms than the general population. When mistakes cannot be easily corrected they can not complete the task.

    This helps people with cognitive disabilities for safely using forms and reduces the consequences that are the result of a mistake.

    For example, a user with a memory impairment may not remember that they have already added an item to their shopping cart and may add the item a second time. They may confused the dates when booking a trip, and many other mistakes.

    It is essential that people with cognitive impairments have the opportunity to check their work AND can fix their mistakes easily.

    For people with cognitive disabilities, mistakes being theoretically reversible is not enough. Often the process of reversing a transaction is too complex for them to manage without help. They may not have access to that help meaning they have to live with all the mistakes they have made. For example, when inputting credit card information incorrectly these mistakes can be devastating. In addition if the process of correcting mistakes is too difficult, users may give up, either losing the transaction or buying unwanted items because of the one required item.

    The effect of this happening multiple times is devastating and can result in a large number of users with disabilities stopping to use the Internet for many tasks.

    Allowing the user to change the number of items in the shopping cart at any time can significantly reduce the chances of these mistakes.

    A summary of the order, including product quantities and other costs before the final submission, gives the user the chance to identify any errors and make changes to the order.In this example given, a summary of the purchase helps the user see the error in quantity as well as a higher than expected order total.

    In some cases a user may realize that a mistake has been made after the final submission of data. Simple language instructions on how to cancel transactions and helping the user understanding the amount of time the user has to cancel a transaction and makes them less susceptible to scams

    In another example, a user with Attention-Deficit/Hyperactivity Disorder purchasing a travel ticket on a website may struggle with details and may have a low attention span. The successful completion of the order relies on the information provided at multiple steps in the process.An error due to lack of accuracy or attention to detail such as an incorrect street number or zip code in the billing address will result in the order not going though. If a summary is not provided before submitting the final order or is not clear the user may not understand the reason for the declined payment and give up on the order. The user may also give up if there is not an easy way to make correction, and all the order needs to be redone.

    5.3.3.2 More details

    This typically includes:

    • Change: It is simple for the user to review all the data and correct mistakes, including mistakes that might not be automatically identified. The user can change information via clearly labeled actions and get back to the place they were at, in one clearly labeled action without unwanted loss of data. (Some data may need to be entered if it is dependent on the item that was changed.)
    • Confirmed: A summary is provided before submitting important information and the user is told when they are about to submit the final information.
    • Time frames and instruction for cancelling transactions are clear and easy to follow.
    5.3.3.3 Getting started

    Start with forms were a mistake can have serious consequences such as financial loss or vulnerability.

    5.3.3.4 Examples

    Success example:

    • Provide a summary before submitting important information. Make it clearly labelled to repair information and one click to return to the summary
    • Provide clickable breadcrumbs that allow users to see the previous steps, go back, and change them

    Failure example:

    • Provide a summary before submitting important information. But it is hard to repair the information
    • Provide a summary before submitting important information. But then you have to redo a lot of other non-dependent information
    5.3.3.5 Technical details

    The following are proposals for WCAG. They experiment with more testable language.

    On coga github: error-prevention-legal.html

    wcag issue 33

    pull request 104

    5.3.4 Use clear labels and instructions

    Labels or Instructions: Provide labels or instructions when content requires user input. Labels and instructions:

    • Fully describe the input's function
    • Use the default format and standards for localized content in the location of the user and allow for changes of format on labels and user input. An exception is provided where any standard format is accepted.
    • Explain where to get the required information. An exception is provided where the information is known by the intended audience.
    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    5.3.4.1 How it helps

    The intent of this design requirement is not only to have content authors implement instructions or labels when content requires user input but for these instructions or labels to be implemented in a way that is beneficial to users with cognitive disabilities. The design requirement is intended to let users know what input data is expected. Implementing labels or instructions that fully describe an input's function alleviates ambiguity. Clear labels and instructions prevent the user from making errors and provide support that helps users complete and check their task.

    For example, when asking for a passport number, provide an image of a passport (with alternative text) that highlights where you can find this number in your passport. Without this information many users will not know how to find the passport number and will be unable to complete the task.

    To fully describe an input's function, the wording on the label needs to be unambiguous so that the function is clear. For example if there is more than one form on a page, having more than one labeled "go" is not clear and the user is likely to make a mistake and go to the wrong place. The label should: clearly identify the full function preventing the user from making mistakes or; the scope of the task should be completely clear via a technique such as adding an instruction in a tooltip or help icon.

    Another example would be an international ecommerce website which accepts multiple currencies. Product pricing includes the currency symbol in addition to the associated standardized text. For example:

    • € 234,56 Euro
    • £ 234,56 British Pounds
    • $ 234,56 US Dollars

    Using the default format for localized content based on the location of the user is also beneficial to users with cognitive disabilities. For example, currently many Web based calendars require settings to be changed to suit the locale. Users may not be aware of the start of the week in the locale, e.g. Sunday in the Middle East, and may be unable to take appropriate actions to suit their needs.

    In some cases a full description of an input's function maybe not be possible for example, if the description would be too verbose or if additional explanation is needed. Explaining where to get the required information can also be helpful for users with cognitive disabilities, giving them a point of reference to the required input. For example, an assignment in an e-learning course may require students to write essays using the "MLA Format for Essays and Research Papers" and provide an indication for this requirement along with a link on how to write in this format along with an example.

    This helps users who need help understanding what input data is expected. This supports users who have:

    • Intellectual disabilities
    • Focus and attention related disabilities including attention with details
    • Memory related disabilities
    • Language related disabilities

    The use of conformant labels or instruction when input is required is particularly helpful for users with cognitive disabilities because

    • In many case users will not understand how to complete a form and where to find information therefore making the task impossible to complete
    • Ambiguous labels and lack of instructions result in user errors. With this design requirement errors can be mitigated before they happen therefore reducing the number of errors which occur during a task. Manual error correction is both difficult and frustrating. Multiple errors and the manual correction of errors results in the likelihood of loss of focus, and/or abandonment of a task.
    • Reducing the number of errors will also reduce the number of error notifications. Multiple error notifications can distract users who have difficulty remaining focused from engaging and completing the primary task.
    • The use of default values shows meaningful results with helping users who are challenged by attention to detail.
    5.3.4.2 More details

    Note: Information is known by the intended audience includes the user's name, phone number, address, date of birth and other information where user testing has shown that the information is known by the intended audience

    5.3.5 Make it easy for the user to undo actions

    Consistently provide the ability to undo any action and to correct previous mistakes such that:

    • A user can go back steps in a process via a clearly labeled action.
    • The user can repair information via a clearly labeled action and get back to the place they were at, via a clearly labeled action, without unwanted loss of data.
    5.3.5.1 How it helps

    An undo feature makes it easy to undo mistakes. It can simplify actions, reduce fear of failure, and make it possible for users to complete their task. It also allows an experimental exploration of a process with confidence that nothing serious will happen.

    Those who have difficulties accurately entering information correctly or perceiving errors will need to undo incorrect actions. It allows all users, but especially those with learning and cognitive disabilities including poor short term memory, to re-check data entered and make necessary changes if errors have occurred.

    5.3.5.2 More details

    The intent is to allow users to easily undo steps or correct previously entered information at any point in a process, and not just at the confirmation prior to submission.

    This is especially important for people with learning and cognitive disabilities, who are likely to make more mistakes. Their mistake might be realized at any point and the need is to correct it immediately so as not to forget to do so later, or else abandoning the whole process.

    In a multi step process where data is entered in each step allow revisiting previously entered data without losing subsequently entered correct data. Each time the user has to re-enter data, there is a new chance for new mistakes to occur so the need needs to be removed.

    Techniques which can enable undo include:

    • Clickable breadcrumbs provided with previous steps providing ‘random access’ to each previously visited step and no data loss
    • Providing back and undo features without unwanted data loss
    5.3.5.3 Technical details

    The following are proposals for WCAG. They experiment with more testable language.

    On coga github: help.html

    wcag issue 38

    5.3.6 Avoid data loss and “time outs”

    Avoid timeouts. When this is not possible inform user of the amount of time required to complete the process (before timeout) and if user will lose entered data if a timeout occurs.

    5.3.6.1 How it helps

    The use of timed events can present significant barriers for users with cognitive disabilities, as these users may require more time to read content or to perform functions, such as completing an online form.

    During the completion of an online process for reserving a hotel room and purchasing a plane ticket, a user with a cognitive impairment may become overwhelmed with the amount of instruction and data input required to complete the process. The user may not be able to complete the process in one sitting, and may need to take a break. Users should be able to leave a process without losing their current place within the process, and without losing data that have already been entered. If users cannot take a break and check their work, many will often be unable to complete a task correctly.

    While making a purchase on an e-commerce Web site, a user with a cognitive disability may not remember required information (e.g., a phone number or a zip code) that may seem easy to remember for users without a cognitive impairment. Users with cognitive disabilities may need additional time to look up the information required to complete a transaction, without losing their place in the process, and without losing data that have already been entered.

    In another example, users’ cognitive skills may temporarily diminish as they get tired. They then must stop the task for that day, and continue it when they are feeling better, and when their reading or processing skills are back to their higher levels.

    For situations where the absence of a timed event would significantly change the intended functionality of an application (e.g., an auction or another real-time event), it is important to ensure that users with disabilities are properly notified. Notifications should include information about timed events, and an indication of the duration of the time given. As well, they should include mechanisms clearly labeled to adjust, extend, or stop the duration of an event, to allow users to fully engage and interact with Web content and functionality. For example, if an e-commerce Web site's checkout process provides secure credit card transactions, the user is notified of the timeout, and is given at least 120 seconds to extend it.

    These experiences have been reported by members of the task force who have various cognitive impairments. There is significant user research indicating that timed events rarely help anyone; and can cause stress and frustration.

    It should be noted that many users, within 20 seconds, cannot read instructions to extend a time limit. We thus extended the time limit to 120 seconds.

    We also require simple text conforming to the understandable language design requirement.

    This helps users who need additional time performing tasks or reading content. This can include the following:

    • A Web site uses a client-side time limit to help protect users who may step away from their computers. After a period of inactivity, the Web page asks if the user needs more time. If the user does not respond within 120 seconds, a timeout occurs. The user is able to request more time at least 10 times.
    • A Web page has a section that automatically updates with the latest headlines in a rotating fashion. There is an interactive control that is easy to activate and is labeled with simple text. It allows the user to extend the length of time, between each update, to as much as ten times the default. The control can be operated by mouse, keyboard, or touch.
    • A ticket-purchasing web site allows users two minutes to confirm purchase of selected seats, but warns users when their time is almost out. It allows users to extend this time limit at least 10 times using a simple action, which is labeled with simple text, such as a button labeled "Extend time limit".
    • In an auction, there is a time limit on the amount of time a user has to submit a bid. Because the time limit applies to all users who want to bid on an item, it would be unfair to extend the time limit for one user. Therefore, a time limit is required for this type of activity. No extension, adjustment, or deactivation of such a time limit is required by this design requirement.

    The design requirement helps people with a variety of disabilities including the following:

    • People with physical disabilities, who often need more time to react, to type, and to complete activities. - People with low vision need more time to locate things on screen, and to read. People who are blind, and who use screen readers, may need more time to understand screen layouts, to find information, and to operate controls. People, who have cognitive or language limitations, need more time to read and to understand. People who are deaf, and who communicate in sign language, may need more time to read textual information (which may be a second language for some).
    • In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.
    • People with reading disabilities, cognitive limitations, and learning disabilities, who may need more time to read or to comprehend information, can pause content to have additional time to read it.
    5.3.6.2 Technical details

    On coga github: timed-events.html

    wcag issue 14

    pull request 116

    5.3.7 Provide feedback

    The success or failure of every user initiated action is clearly indicated to the user by visual, programmatically-determinable, rapid feedback in the primary modalities of the content. Audio feedback is supported.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    5.3.7.1 How it helps

    Applications should consistently provide easily-recognizable success or failure feedback with every user action.For example:

    • After a step in a multi-step task is completed, breadcrumbs display a tick or a checkmark next to that step's name; and, if applicable, the title or the name of the next step is readily apparent.
    • After a button is clicked, it should look depressed. (Note that if it is a toggle button, the state should also be programmatically determinable).
    • After a form is submitted or an email message is sent, feedback communicating what just happened, such as "Your application was submitted, thank you" or "Your email message was sent" is provided.

    Overt indication of the result stemming from a user action helps people with a variety of cognitive disabilities:

    • understand that their action occurred (e.g., the click did something);
    • prevent uncertainty or doubt regarding the outcome; and
    • remember what they just did.

    User-action feedback during a multi-step task can also assist people, with attention or short-term cognitive disabilities, avoid inadvertently leaving a task by reminding them that they are in a process, and where in the process they currently are.

    This information supports those who have Aphasia, Dementia, Dyslexia, or those who acquire cognitive disabilities as they age. It also helps anyone with impaired short-term memory remember what they just did.

    5.3.7.2 Examples

    Success example:

    • Use WAI-ARIA states to provide state feedback for a toggle button with an animation showing the state (such as a button was pushed )
    • Use ARIA-pressed with a visual or a checkbox is checked/unchecked,
    • Provide a confirmation message when an email message is successfully sent, or a form is successfully submitted.
    • Use a progress-indicator element (e.g., breadcrumbs) to communicate completed and current steps in a multi-step process.
    • Provide visible and programmatically-determinable information to indicate a new password satisfies security requirements.
    5.3.7.3 Technical details

    The following are proposals for WCAG. They experiment with more testable language.

    On coga github: feedback.html

    wcag issue 54

    pull request 109

    5.3.8 Tell the users about any fees and charges at the beginning of a task

    Identify Charges: All types of charges are identified at the start of transaction tasks. When a minimum or typical value is known for a type of charge it must be made clear at the start of the transaction task. Conditions and terms are available at the start of transaction tasks.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    5.3.8.1 How it helps

    Final transactions do not include charges or conditions that are unknown because they are not apparent to a user at the start of a transaction task. Identifying charges and conditions at the start of a transaction task will give the user necessary information, allowing them to decide whether to start a process that includes a transaction or not.

    Under Guideline 3.3 the current design requirement focuses on user input and help but does not include a design requirement that mitigates mistakes as a result of unknown information such as charges and conditions. Users with cognitive disabilities who have trouble with memory, attention to detail or reading comprehension may not be aware of charges unless they are explicitly noted at the start of a transaction task. We allow terms and conditions to be under a link but charges must be clearly displayed.

    Clearly identifying charges and conditions at the start of a transaction task benefits all users. Those with cognitive disabilities will particularly benefit from clear identification at the start of a transaction task, particularly if the charge or condition is inferred, assumed or only identified early in the user flow or in another location, for example on the homepage.

    People with impaired Executive Function or memory, need to have all the consequences presented in an orderly form to be able to make an informed decision. When charges are not clear, the consent of the transaction is unclear.

    Further, people with Learning and Cognitive disabilities are particularly susceptible to scams and marketing tricks. It also can take much longer for users with disabilities to go through the process of making a purchase. If a person has spent hours making an online purchase, it is much more difficult and upsetting to find out that they cannot afford it. They will often blame themselves for not understanding the price and may experience a loss of confidence. They may stop trusting themselves for day-to-day activities.

    This design requirement has the following benefits:

    • Final transactions will not include unknown charges that result in higher-than-expected total charges
    • Final transactions will not include conditions of purchase that are not apparent to users.
    • Users will not engage in transactions that contain charges or conditions that they do not want.
    • Users will be more likely to make an informed decision
    5.3.8.2 Technical details

    On coga github: identify-charges.html

    wcag issue 37

    5.3.9 The user knows when the content changes

    Changes of context, functionality, settings, route and orientation are initiated only by user request or an easily available mechanism is available to turn off such changes. An easily available mechanism is also available to go to previous context, functionality, settings, route and orientation.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    5.3.9.1 How it helps

    Any content, settings or functionality which changes unexpectedly, without user initiation can result in significant barriers for users with cognitive disabilities. Unexpected changes in any of these areas can result in loss of focus, anxiety, or confusion in understanding or using a user interface (such as menus, buttons and design components). Examples include but are not limited to:

    • Automatic launching of new windows or pop-ups
    • Submission of forms through mechanisms other than a button that is clearly labeled using simple language to submit the form
    • Rerouting automatically by a GPS
    • Changing the direction of a map in a GPS

    For example, a user may not have a sense of direction or know their left and right. Before using a GPS they may study the route so that they know approximately what they are doing and can augment the directions of the GPS with their own context, using the GPS for cues. The GPS automatically reroutes them because of a small traffic delay. They become completely lost and disorientated and can no longer use the application.

    This give users with cognitive disabilities more control over how Websites and applications behave and display information giving them the opportunity to make choices that enable them to use the content and complete the task.

    5.3.9.2 More details

    Exception: The changes are part of an activity where it is essential (e.g. a game)

    route: Directions and flow such as a GPS route

    orientation: perspective or view such as map direction

    easily available (or easily available mode or setting): one or more of the following is true:

    • can be set one time with as a wide a scope as possible (such as using the standards of the OS, From ISO 9241-112 or GPII when available);
    • with the option to save or to change the setting, were available interoperably, but also for the scope of the set of web pages;
    • is reachable from each screen where it may be needed, and the path and the control conforms to all of this document.
    • can be set one time with as wide a scope as possible (such as using the standards of the OS, ETSI or GPII when available); and
    • with the option to save or to change the setting, were available interoperably, but also for the scope of the set of Web pages; and
    • is reachable from each screen where it may be needed, and the path and the control conforms to all of the document.

    5.3.10 Keep the user information safe

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information

    User Information: Use known techniques to keep sensitive user information safe that can be used to identify the user or identify that user may have a disability. Warn users of any known risk.

    5.3.10.1 How it helps

    Don’t store personal information that could be used to harm a user without being very careful to minimise any risk to the user.

    5.3.10.2 Examples

    Storing information, which suggests a user has Dementia, may make a target for scams; or storing information, which suggests a user has an intellectual disability, may make a target for predators.

    A predatory company could send requests for money, saying “you haven’t made your donation” despite the user having made one.

    It is vital that users stay safe.

    Another consideration is that many users have weak executive functioning, and are thus less likely to identify risks correctly.

    The benefit of this requirement is to keep users safe while online.

    5.3.10.3 Technical details

    On coga github: user-information.html

    wcag issue 25

    6. Theme 5: Help the user focus and restore context if attention is lost.

    Distractions can cause users with cognitive disabilities problems such as:

    Once users become distracted, it can be difficult for them to remember what they were doing. Then they can no longer complete their task at all. This is especially problematic for users with both low attention and impaired memory, such as users with dementia.

    Items like bread crumbs 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.)

    6.1 User testing - Help the user focus

    Make sure your user testing has all the different cognitive disabilities represented. Test for the following:

    Identify the different tasks:

    6.2 Example user stories: Help the user focus

    As a user who is easily distracted I need less distractions from my task.

    As a user with a poor memory I need easy sign posts about what is on the screen, where I am in a process and what i am doing, incase I get distracted in the middle of a task.

    6.3 Design guidance: Help the user focus

    6.3.1 Avoid interruptions

    Avoid interruptions such as popups and changes in context.

    If you can not avoid them, make an easy way to delay and control interruptions and changes in content, unless they are started by the user or involve an emergency.

    6.3.1.1 How It Helps

    For people with memory or attention challenges, interruptions can make completing a task very difficult or impossible. This can include individuals with Dementia, those that have had a stroke or brain injury, and those taking medications with side effects impacting memory and/or attention. Certain types of interruptions or a certain number may cause them to give up, even if the task is very important. Interruptions can include sounds, content that visually appears or changes (e.g. ads on a page). It can be as simple as text notifications about the presence of new changes while working in a shared online document.

    A site will work best for those with memory or attention challenges if they:

    • Have no interruptions at all,
    • Have an easy to use pause option so interruptions can be viewed later, or
    • Have a setting where users can select which types of interruptions they prefer.

    Many news websites have a lot of interruptions that can cause challenges for people needing to read important information, such as school closures due to bad weather. They may encounter breaking news text, advertisements, and pop-up windows. For those with difficulty focusing and sifting through the school names, or have two or three they need to check, these distractions may make the task impossible. By letting the user pause these distractions, and ideally temporarily remove them from the page, they will better be able to complete the task.

    Where standard techniques exists for the above, they should be used.

    6.3.1.2 Examples

    Good example: Microsoft Office 365 Notifications

    Microsoft Office 365 lets the user decide how they want to be notified about reminders and emails. Users can choose visual reminders and/or sounds, or none. 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.

    Poor example: Magazine Ads

    There are advertisements on the Magazine article pages that interrupt a reader’s focus. In the example below, the ad just under the banner changes (black oval) and the ad below the first article photo (navy rectangle) change every 20 seconds.

    6.3.1.3 Technical details

    The following are proposals for WCAG. They experiment with more testable language.

    On coga github: interruptions.html

    wcag issue 47

    pull request 98

    6.3.2 Avoid too much content on the page

    Allow users to have content with less than five choices on each screen. This can be a simplified version or a have extra choices behind a “more” feature.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information

    7. Theme 6: Avoid barriers

    Do not put barriers that stop people with cognitive disabilities from using or getting to content.

    Many users have memory issues and/or language issues that can make remembering passwords or remembering numbers, while processing words, difficult or impossible. That can make transcribing text or remembering passwords difficult or impossible.

    Sometimes security and authentication put a barrier between users and the tasks they are doing. For example, requiring remembering and/or transcribing passwords often blocks users with cognitive disabilities from accessing content or using a service.

    Sometimes developers put a menu barrier between users and the task they are doing so users cannot use the content or service.

    Voice XML enables voice dialog systems and voice browsers. An example might be a phone menu system that ask you “dial 1 for internal services, dial 2 for external services, .dial 9 for billing services “. Sometimes users need to hold multiple pieces of transitory information in their minds, such as a number being presented as an option, while processing terms that follow. Many people with impaired short term memory can not hold more than two or three pieces of information in their at the same time so they can not do this task and can not get to the place they need to be.

    When possible, provide easy-to-use options.

    Note that a lot can be achieved through supporting personalization.

    7.1 User testing - Avoid barriers

    Make sure your user testing has all the different cognitive disabilities represented. Test for the following:

    Identify the different activities that the user may want to complete on the page:

    7.2 Example user stories: Avoid barriers

    This leads to the following user stories for logging in:

    This leads to the following user stories for voice menus:

    7.3 Design guidance: Avoid barriers

    7.3.1 Logging in does not rely on good memory or other cognitive skills

    Users can login and register without having more cognitive abilities then they need to use a simple web page. This includes:

    • memorizing character strings,
    • perform calculations, or
    • coping; or
    • Answer puzzles; or
    • reliably produce gestures; or
    • recognize characters presented on screen, and then enter them into an input field.
    7.3.1.1 How it helps

    Many people with week memory often lose the password and not be able to login and use their applications. Their solutions often are only sometimes helpful and have security risks:

    • may have to look at or listen to text several times to copy or type it into a form field;
    • may reuse a single passwords; or a simple-to-remember passwords, which they can remember. This is a security risk
    • If they need to change their password or use a complicated password they may keep passwords insecurely, such as written on pieces of paper which people can see.

    The may also struggle with other steps of login

    • enter characters in the correct order;
    • enter characters correctly on the first try (resulting in being locked out).Some people with cognitive disabilities may not be able to:
    • find a PIN;
    • work out puzzles or distorted letters
    • They can also give up after getting frustrated with time-limited procedures or presentations of digital security tokens;

    Without this design requirement, many people cannot use an application or content at all. See Security and Privacy Technologies issue paper for the full description of this issue, and how it stops people from using web services that are often critical. Many people cannot make doctors’ appointments, etc., by themselves. This may be partly responsible for the reduced life expectancy of people with learning and cognitive disabilities.

    7.3.1.2 More details

    There are many ways to meet this design guidance item.

    • Use Web Authentication: An API for accessing Public Key Credentials
    • Automatic user authentication based upon the use of a trusted device (to which the user has already logged in with their own identity);
    • Biometrics
    • being already logged in to third-party authentication services (e.g., OAuth, Facebook, etc.).
    • Methods of meeting requirements for alternative user authentication would include:
      • Clicking a link sent to an email address or a phone number; (Note that this is easy to implement and may be useful for minimal security, such as allowing comments on a blog)
      • Logging in by using information present in users' personal documentation, such as the total number of a current account balance, with explanation on how to find this information.
    7.3.1.3 Getting started
    7.3.1.4 Examples

    Success example:

    Web Authentication: An API for accessing Public Key Credentials

    Logging in via google or facebook

    Two step authentication and bluetooth link

    Using QRC

    Failure example:

    Two step authentication that requires coping

    Using a password

    7.3.1.5 Technical details

    The following are proposals for WCAG. They experiment with more testable language.

    On coga github: accessible-authentication.html

    wcag issue 23

    pull request 91

    7.3.2 Let people avoid navigating voice menus

    Let people easily reach an operator without going through multiple steps.

    7.3.2.1 How it helps

    Many people cannot use voice menu systems and other complex systems. This often stops people from critical tasks by themselves. Often this can include: making doctors' appointments, getting health insurance, reaching social services, get their water turned back on, etc..

    If people can not manage menus by themselves they have to ask someone else to help them. For example they may delay making a doctor’s appointment or other critical task as not to bother their helper. This is a huge problem and means people often do not get the help they need or get it too late. This may be partly responsible for the lower life expectancy of people with learning and cognitive disabilities.

    See Voice Menu Systemsissue paper for a full discussion.

    Why can’t people use complex menus?

    A good short term memory (several seconds) is essential so that the user can remember the number or the term for the menu. Without these functions the user is likely to select the wrong number.

    Many users have a small short term memory. For example, if you can remember 7 letters or items in your head at the same time they may be able to remember one or two. This makes them less likely to manage a menu system correctly. For example a phone menu system (voice ML system) may have an option:

    "Press 3 for internal services" To use this option the user must remember a digit 3 whilst figuring out if they need an internal service. Many people can not do this. It also requires them to press the correct digit.

    When a lot of irrelevant information is given before the correct option the user may give up, especially if they did not understand all the earlier options and information

    Allowing the 0 digit to get to a person, or having the first option "to weight for an person who can help you press 0" can consistently help

    7.3.2.2 More Details

    Considerations for Speech Recognition

    • For speech recognition based systems, an existing ETSI standard for voice commands for many European languages exists and should be used where possible [ETSI 202 076], keeping in mind that expecting people to learn more than a few commands places a burden on the user.
    • Natural language understanding systems allow users to state their requests in their own words, and can be useful for users who have difficulty remembering menu options, or who have difficulty mapping the offered menu options to their goals. However, natural language interfaces can be difficult to use for users who have difficulty producing speech or language. Directed dialog (menu-based) fallback or transfer to an agent should be provided.

    Follow requirements of legislation

    For example, the U.S. Telecommunications Act Section 255 Accessibility Guidelines [Section255] paragraph 1193.41 Input, control, and mechanical functions, clauses (g), (h) and (i) apply to cognitive disabilities and require that equipment should be operable without time-dependent controls, the ability to speak, and should be operable by persons with limited cognitive skills.

    7.3.2.3 Getting started

    This is essential for critical systems such as health, finance, communication, water and government services.

    Not important systems might only use the design requirement bellow (XX)

    7.3.2.4 Examples

    Success example:

    Using user interaction dialogs in which the first option "to weight for a person who can help you press 0”.

    Using a user-interaction dialog, such as the standard "0" from any point, where there is easy access to a human operator who can help users achieve their goals.

    Advisory technique: Cue users to write something that may be useful at a later point, and give them time to do so.

    Failure example:

    Long menu systems that make it hard to find a person

    7.3.2.5 Technical details

    The following are proposals for WCAG. They experiment with more testable language.

    On coga github: task-completion.html

    wcag issue 21

    7.3.3 Do not rely on users memorizing information

    • Each step in a sequential process must contain the information necessary to allow a user to proceed (and so must not rely on memory from prior steps, and would benefit from a summary of info, or a mechanism for traversing the process.
    • Labels are before the activation mechanism
    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    7.3.3.1 How it helps

    Often content has barrier which prevent users with learning disability from completing a step, and as a result, which prevents them from achieving whatever they wished to achieve.

    This often happens in multi-step user-interaction dialogs, such as voice-menu systems, but it can happen in any task including online shopping or forms.

    • Some systems assume that all users have a good working memory. They present several choices to the user and ask them to select one choice, whether by speaking or through a key press. The user needs hold multiple pieces of transitory information in the mind. For example many users have a small short term memory. For example a phone menu system (voice ML system) may have an option: "press 3 for internal services" To use this option the user must remember a digit 3 whilst figuring out if they need an internal service. Many people can not do this. It also requires them to press the correct digit.
    • Reduced executive function may also cause problems. Sometime the user needs more time to complete a task. But she can be problems also if when the system response is too slow. The user may not know whether their input has registered with the system, and consequently may press the key or speak again.
    • The use needs may need to compare similar options such as "billing", "accounts", "sales" and decide which is the service that is best suited to solve the issue at hand. Without strong reasoning skills the user is likely to select the wrong menu option.
    • Advertisements and additional, unrequested information also increase the amount of processing required.
    • The use needs to focus on the different options and select the correct one. A person with impaired attention may have not be able to focus for a long or multi level menu. Advertising and additional, unrequested information also make it harder to retain attention.
    • The user needs to interpret the correct terms and match them to their needs within a certain time limit. This involves speech perception and language understanding: sounds of language are heard, interpreted and understood, within a given time.
    • The user needs to understand the terms used in the menu, even if they are not relevant to the service options required.
    • When a lot of irrelevant information is given before the correct option the user may give up, especially if they did not understand all the earlier options and information.

    Allowing the 0 digit to get to a person, or having the first option "to weight for an person who can help you press 0" can consistently help.

    7.3.3.2 More details

    Follow best practices in general VUI design

    Standard best practices in voice user interface apply to users with cognitive disabilities, and should be followed. A good reference is published by The Association for Voice Interaction Design Wiki [AVIxD]. Another good reference is [ETSI ETR 096]. Some examples of generally accepted best practices in voice user interface design:

    • Pauses are important between phrases in order to allow processing time of language and options.
    • Options in text should be given before the digit to select, or the instruction to select that option. This will mean that the user does not need to remember the digit or instruction whilst processing the term. For example: The prompt "press 1 for the the secretary," requires the user to remember the digit 1 while interpreting the term "secretary". A better prompt is "for the secretary (pause): press 1" or " for the secretary (pause) or for more help (pause): press 1"
    • Error recovery should be simple, and take the user to a human operator if the error persists. Error responses should not end the call or send the user to a more complex menu.
    • Advertisements and other extraneous information should not be read as it can confuse the user and can make it harder to retain attention.
    • Terms used should be as simple and jargon-free as possible.
    • Tapered prompts should be used to increase the level of prompt detail when the user does not respond as expected.

    See the AVIxD wiki cited above for additional recommendation and detail.

    User settings

    User-specific settings can be used to customize the voice user interface (such as menus, and options) , keeping in mind that the available mechanisms for invoking user-specific settings are minimal in a voice interface (speech or DTMF tones). If it is difficult to set user preferences, they won't be used. Setting preferences by natural language is the most natural ("slow down!") but is not currently very common.

    • Extra time should be a user setting for both the speed of speech and ability for the user to define if they need a slower speech or more input time etc.
    • Timed text should be adjustable (as with all accessible media).
    • The user should be able to extend or disable time out as a system default on their device
    • Error recovery should be simple, and take you to a human operator. Error response should not though the user off the line or send them to a more complex menu. Preferably they should use a reserved digit.
    • Timed text should be adjustable (as with all accessible media).
    • Advertisement and other information should not be read as it can confuse the user and can make it harder to retain attention.
    • Terms used should be as simple as possible.
    • Examples and advice should be given on how to build a prompt that reduces the cognitive load
      • Example 1: Reducing cognitive load: The prompt "press 1 for the the secretary," requires the user to remember the digit 1 while interpreting the term secretary. It is less good then the prompt "for the secretary (pause): press 1" or " for the secretary (pause) or for more help (pause): press 1"
      • Example 2: Setting a default for a human operator as the number 0

    Considerations for Speech Recognition

    • For speech recognition based systems, an existing ETSI standard for voice commands for many European languages exists and should be used where possible [ETSI 202 076], keeping in mind that expecting people to learn more than a few commands places a burden on the user.
    • Natural language understanding systems allow users to state their requests in their own words, and can be useful for users who have difficulty remembering menu options, or who have difficulty mapping the offered menu options to their goals. However, natural language interfaces can be difficult to use for users who have difficulty producing speech or language. Directed dialog (menu-based) fallback or transfer to an agent should be provided.

    Follow requirements of legislation

    For example, the U.S. Telecommunications Act Section 255 Accessibility Guidelines [Section255] paragraph 1193.41 Input, control, and mechanical functions, clauses (g), (h) and (i) apply to cognitive disabilities and require that equipment should be operable without time-dependent controls, the ability to speak, and should be operable by persons with limited cognitive skills.

    7.3.3.3 Getting started

    This is essential for critical systems such as health, finance, communication, water and government services.

    Not important systems might only use the design requirement bellow (XX)

    7.3.3.4 Examples

    Success example:

    Using user interaction dialogs in which the first option "to weight for a person who can help you press 0”.

    Using a user-interaction dialog, such as the standard "0" from any point, where there is easy access to a human operator who can help users achieve their goals.

    Advisory technique: Cue users to write something that may be useful at a later point, and give them time to do so.

    Failure example:

    Long menu systems that make it hard to find a person more requirement. The user can figure it out and then hears the digit they need

    7.3.3.5 Technical details

    On coga github: task-completion.html

    wcag issue 21

    8. Theme 7: Provide help and support

    Note that a lot can be achieved through supporting personalization.

    8.1 User testing - Provide help and support

    Make sure your user testing has all the different cognitive disabilities represented. (Make sure people don't just ask these as questions, but ask something that demonstrates it.)

    Test for the following:

    8.2 Example user stories: Provide help and support

    This leads to the following user stories.

    8.3 Design guidance: Help and Support

    8.3.1 Provide help for complex information

    Content is provided that helps users understand complex information

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    8.3.1.1 How it helps

    The use of complex information, long documents and data in a particular format and the use of non-standard controls in Web forms can present significant barriers to users with cognitive accessibility needs. The intent of this design requirement is to ensure that navigation, operability and the ability to complete tasks associated with a website is fully understandable and accessible to people with cognitive accessibility needs through the provision of context sensitive help, tooltips and explanation of jargon. For example:

    • Promoting clarity when complex information is presented by providing a summary or keywords will make the information more accessible to all users, especially users with cognitive accessibility needs.
    • People who find reading or language difficult can be helped by a chart or graph.

    The main reason for the upgrade in the conformance level is to ensure that user needs are consistently addressed across the different disabilities.

    Note that graphics should be clear and it should be easy to identify meaning and context. The ability to "read between the lines"; of a text, graphic, or lecture may seem obvious to many users without cognitive accessibility needs but it may create barriers for people with autism, who may not be able to readily discern the intended relevance of graphical data.

    Further use aria-describedby to associate the graphic or sections of a graphic or chart and the text that describes it can be read by a screen reader while the right section of the chart is highlighted.

    The benefit to users with cognitive accessibility needs is that the information in the help is presented in a way that it is understandable and therefore supports the user in accessing the information or service which would otherwise be too complex for them to consume. This design requirement addresses two broad classes of issues associated with this type of information:

    • If the user perceives the activity to be too complex the user may decide to abandon the activity and therefore be excluded from the information and/or services derived from the completion of the activity.
    • If the activity relies on the comprehension of complex information, long documents, data in a particular format or non-standard controls then the likelihood of errors being made during the activity increases, particularly for users with cognitive accessibility needs

    While providing clarity and accessibility is of benefit to all users it is of particular benefit to a wide range of users with differing cognitive accessibility needs including users with:

    • Language related disabilities
    • Memory related disabilities
    • Disabilities that effect executive function and decision making
    • Focus and attention related disabilities

    Providing comprehensive help not only benefits users with diverse cognitive accessibility needs but also benefits any user who is unfamiliar with the material and therefore the benefits are not restricted to a relatively small subset of users.

    Sufficient techniques for icons and jargon

    Ensure one of the following techniques are used:

    • All icons and jargon have a short explanation available. (Where a standard mechanism exists for the platform or technologies it should be used. (COGA Techniques 2.7)
    • Using COGA semantics to supply a short explanation for icons or jargon
    • Short tooltips on all icons and jargon that clarify the meaning are provided.
    • WCAG 2.0 Technique G62: Providing a glossary.

    Sufficient techniques for content relating to numbers and complex information. (use whichever apply)

    • Charts or graphics are provided where they aid the comprehension of complex information. (COGA Techniques 2.7.3)
    • Tables are provided where they aid the comprehension of information.
    • Where an understanding of mathematics is not a primary requirement for using this content use one of the following:
      • Reinforce numbers with non-numerical concepts, e.g., Very Cold, Cold, Cool, Mild, Warm, Hot, Very Hot
      • Using COGA semantics to supply a non-numerical concepts
    • For content with sections use one of the following:
      • Using enable semantics to add symbols to sections
      • Adding symbols as an addition to headings, key short sentences and phrases to aid understanding.
      • However as some people have difficulty remembering symbols, use text with the symbol.
        • Use clear symbols that can easily be seen and expanded
        • Use images understood by different users
        • In left to right languages place the image to the left of the text
    • Sufficient techniques for content with more than 300 words
      • WCAG 2.0 Technique G86: Providing a text summary that can be understood by people with lower secondary education level reading ability. For pieces of content with less than 300 words the heading may act as a summary.
      • Semantic headings are used to break the information down into a more manageable size and provide structure to the information being presented. This particularly benefits users of Assistive Technology.
      • The content owner identifies at least two keywords that aid comprehension for the user and these keywords are programmatic determinable and emphasized in the modality of the user.
      • Using COGA semantics to identify keywords
      • Using COGA semantics to supply a summary
      • Using a plugin to supply a summary
    8.3.1.2 Technical details

    On coga github: help.html

    wcag issue 32

    pull request 118

    8.3.2 Provide help with directions

    Content is provided that helps users understand directions

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    8.3.2.1 How it helps

    People who do not know their left from right will be able to use navigation systems.

    For relative and cardinal directions (North, South, East, and West),

    • Using a standard mechanism for the platform or technologies exists for personalization of relative and cardinal directions and terms
    • Providing alternative terms relative and cardinal directions (North, South, East, and West) where personalization is not supported
    8.3.2.2 Technical details

    On coga github: help.html

    wcag issue 32

    pull request 118

    8.3.3 Provide help for forms and non-standard controls

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information

    Content is provided that helps users understand forms and non-standard controls.

    8.3.3.1 How it helps

    Sufficient techniques for forms

    • Using a standard mechanism for the platform or technologies exists for context sensitive help
    • Using COGA semantics for context sensitive help
    • Semantic headings are used to provide a logical structure to a form adding both the understanding of the form layout and the information required. This will also benefit users of Assistive Technology.

    Sufficient techniques for non-standard controls

    • Clear and non-ambiguous instructions should be available for non-standard controls.
    • Using COGA semantics for instructions should be available for non-standard controls
    8.3.3.2 Technical details

    On coga github: help.html

    wcag issue 32

    pull request 118

    8.3.4 Provide human help

    Ensure easy access to a human who can provide help and support. Support can be on accessibility, technical, process or domain based.

    Access to human help should never require the user to manage complex menu systems such as voice menus with different options.

    8.3.4.1 How it helps

    In cases where the user gets stuck or confused for any reason, contact with a human is usually the most effective and suitable solution. Otherwise the user may abandon the process and be left with negative attitude towards the service or supplier.

    One or more contact mechanisms should be easy to locate and use from any page or any step in a process.

    8.3.4.2 More details

    Examples include

    • An option for live chat or video call help. Note: It must be full accessible and easy to close new windows that open as part of live help functionality.
    • A phone number, ideally with a feature to automatically call via an interoperable Voice over IP specification.
    • A simple site contact form.
    • An email link using the ‘mailto’ protocol with prefilled “to” and “subject” fields. Note will not work on all platforms or depending of the users mail client
    • Use available standards to get human help for example, using the 0 digit on voice menu systems

    It is important that voice communication is easy and this implies the person providing help can both be easily understood and is able to understand others, allowing for a range of vocal and verbal characteristics. Sensitivity to the requirements of people with learning cognitive disabilities is also important.

    8.3.4.3 Examples

    Success example:

    Failure example:

    8.3.4.4 Technical details

    The following are proposals for WCAG.

    On coga github: extra-help-aaa.html

    wcag issue 52

    8.3.5 Provide reminders

    The user is able to set a reminder for date and time sensitive events. Reminders must be set only at the users request and the user must be able to personalize the reminder method. Where a standard mechanism exists for the platform or technologies, it must be used.

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information
    8.3.5.1 How it helps

    Managing events that are time bound (such as meetings, submitting a request by a certain date or completing a form within a specified time period) can present significant barriers to users with cognitive accessibility needs. The intent of this design requirement is to ensure that when required, a user can set reminders and the delivery method of the reminder can be personalized by the user.

    For example:

    • A user may have difficulty processing and retaining time based information.
    • A user may have difficulty in sequencing time bound events.
    • A user's skills decreases when tired to such an extent that they have to stop a task. They may wish to reschedule the task.

    The benefit to users with cognitive accessibility needs is that they can manage appointments, deadlines and schedules. The ability to set reminders can reduce the cognitive load associated when processing time bound tasks. Time dependent activities may be monitored and tracked by the user to ensure that they are completed in a timely manner. This design requirement addresses two broad classes of issues associated with this type of information:

    • If the user perceives the activity to be too complex the user may decide to abandon the activity and therefore be excluded from the information and/or services derived from the completion of the activity.
    • If the activity relies on a number of distinct events being carried out sequentially over an extended period of time or if a single event must be completed by a specified date and time then the likelihood of errors being made during the activity increases, particularly for users with cognitive accessibility needs. Activities are often missed because the date and time is confused.

    While the ability to set reminders is of benefit to all users, it is of particular benefit to a wide range of users with differing cognitive accessibility needs including users with:

    • Learning disabilities
    • Cognitive and memory related disabilities
    • Disabilities that effect executive function and decision making
    • Focus and attention related disabilities

    Providing a mechanism to allow users to set reminders not only benefits users with diverse cognitive accessibility needs but also benefits any user who uses electronic calendars and task managers. Therefore, the benefits are not restricted to a relatively small subset of users.

    8.3.5.2 More Details

    Date and time sensitive event:

    Any event that has to be completed by a certain time. The time constraints on such an event may be defined by a calendar date and time or by the total elapsed time.

    8.3.5.3 Technical details

    The following are proposals for WCAG.

    On coga github: reminders.html

    wcag issue 34

    8.3.6 Support API’s

    Editor's note

    Editor's note: This design requirement needs more work. This may include:

    • Making it easier to understand
    • Fitting it to our template
    • Adding more information

    Standardized APIs: Support known standardized API's for tools that help the user understand and use the content.

    8.3.6.1 How it helps

    Support compatibility with assistive technology and standardized personalization. The definition of standardized API's are identified in the native platform's documentation or in a WCAG technique. This is important as the design requirement is not open ended.

    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.

    This includes:

    • Support of standards for the Internet of Things that allow for simplified and personalized interfaces such as the ISO/IEC 24752 “Universal Remote Console Framework” standard
    • Standardized techniques to support interoperable symbol sets that are used when available.
    • Allow reading of the long form of acronyms
    • Support for text-to-speech with synchronized highlighting of the phrase being read
    • Content simplification
    • Creating mind maps out of the heading structure
    • Support for retaining content that has already been entered
    • Password management
    • Spell checking

    People with, Attention-Deficit/Hyperactivity Disorder, Alzheimer's disease and other forms of dementia, traumatic brain injury, or weak executive function can experience memory impairments impacting their ability to remember details such as:

    • The Internet of Things (IoT) interface
    • Their user name and password
    • What an acronym stands for
    • A phone number
    • The meaning of uncommon words

    Poor working memory (i.e. difficulty holding on to several pieces of information at the same time) may also be experienced by people with these types of disabilities.

    Providing access to simplified content and certain types of content (e.g. the long form of acronyms) helps, and in some cases is necessary, to allow people with cognitive disabilities an opportunity to comprehend the content.

    Supporting password management tools enables people with memory-related disabilities to successfully login and avoid being locked out of secure sites.

    Storing non-sensitive, user-provided information offers the means for completing a task in manageable pieces rather than all at once. This is especially helpful for people with ADHD as well as other cognitive disabilities, who may become distracted and logged out, or fatigued while filling out a form.

    Suggesting common information, like a person's phone number or address when encountering form fields requesting this type of information, helps all people, especially those with cognitive disabilities, avoid making mistakes. It also eliminates the need for accurately recalling this information from memory or having to copy and paste it, which is a task that can prevent successful interaction with a form.

    When people with literacy impairments or autism are unable to understand, or when they become overwhelmed by textual content, support for interoperable symbol sets can provide a way for the content to be comprehended.

    The Internet of Things (IoT)

    Individuals with lower literacy may have different reading patterns than high-literacy readers when it comes to understanding displays for “smart objects.” While high-literacy readers scan text, low-literacy users may read the text “word-for-word.” This can create a narrow field of view which may cause them to miss objects and information not directly in the flow of text that they are reading. For example, low-literacy users might miss information that is essential for successfully completing an interaction with wifi for remote monitoring.

    Too many options may add to the complexity of interacting with IoT devices. Additional options should be easy to ignore and not require a lot of reading to understand that they are additional, as well as how to skip them.

    Sometimes IoT interfaces may confuse the user, such as a default "reading" on a meter being set to “2” and not “1.” The user would then need to reset it to “1.”

    It is important in any proposed solution to make operational tasks, such as interacting with the IoT, as transparent as possible so that users can focus their attention on the functional aspects, such as relating to content. The following solutions support general usability of the IoT for everyone, in addition to assisting those with cognitive disabilities.

    8.3.6.2 More details

    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

    The task force discussed this paper on 0/03/2015 and felt that the following changes should be made to the content below:

    • We want interfaces either to support adaptability, be compatible with supportive API's, or provide an alternative, simplified control. We cannot expect only standard controls to be used.
    • A lot of this will be covered by the API's such as URC
    • We need to review that the API's provide the support we need, such as less features.
    • We need to ensure web interfaces have the needed semantics, such as via ARIA. See personalization semantics.
    8.3.6.3 Technical details

    The following are proposals for WCAG.

    On coga github: standardized-apis.html

    wcag issue 46

    9. Theme 8: Feedback is usable by everyone (merge with above?)

    Note that a lot can be achieved through supporting personalization.

    9.1 User testing - Feedback is usable by everyone

    Make sure your user testing has all the different cognitive disabilities represented. Test for the following:

    9.2 Example user stories: Feedback is usable by everyone

    As a user with a cognitive disability I want to be able to give feedback easily

    As a user with a cognitive disability I want to be able to give feedback as soon as I get stuck from any part in the process

    I want to be able to give feedback in any form that other people can. When i try and give feedback and can not manage I know I am excluded and the website does not care about me.