Cognitive Accessibility Roadmap and Gap Analysis

W3C First Public Working Draft

This version:
https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/
Latest published version:
https://www.w3.org/TR/coga-gap-analysis/
Latest editor's draft:
https://w3c.github.io/coga/gap-analysis/
Editors:
Lisa Seeman,
Michael Cooper, W3C,

Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

Abstract

This document is a gap analysis and roadmap for the state of accessibility for people with learning and cognitive disabilities when using the Web and information technologies. It builds on the information presented in Cognitive Accessibility User Research [coga-user-research] and Cognitive Accessibility Issue Papers [coga-issue-papers] to evaluate where user needs remain to be met in technologies and accessibility guidelines. For various accessibility issues, this document provides a summary of issues and techniques, then identifies gaps and unmet user needs and suggest ways to meet these needs.

This document is part of a set of related informative publications from the Accessible Platform Architectures Working Group (APA WG) and the Accessibility Guidelines Working Group (AG WG) of the Web Accessibility Initiative.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Accessible Platform Architectures Working Group and the Accessibility Guidelines Working Group as a First Public Working Draft. This document explores user needs for people with cognitive or learning disabilities and identifies where additional web content authoring guidance is needed to help authors meet these needs. This information is important to new guidance being added to Web Content Accessibility Guidelines 2.1.

Feedback on any aspect of the document is accepted. For this publication, the Working Groups particularly seek feedback on the following questions:

To comment, file an issue in the W3C coga GitHub repository. If this is not feasible, send email to public-coga-comments@w3.org (comment archive). Comments are requested by 16 January 2018. In-progress updates to the document may be viewed in the publicly visible editors' draft.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by groups operating under the W3C Patent Policy. The groups do not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures (Accessible Platform Architectures Working Group) and a public list of any patent disclosures (Accessibility Guidelines Working Group) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2017 W3C Process Document.

1. Introduction

This section is non-normative.

The Cognitive and Learning Disabilities Accessibility Task Force's aim is to improve web accessibility for people with cognitive and learning disabilities. This is being done as part of the Web Content Accessibility Guidelines (WCAG) and Accessible Platform Architecture Working Group (APA WG), part of the Web Accessibility Initiative (WAI) of the W3C. Challenges facing this work include:

Addressing these issues requires us to make a broader view of solutions for accessibility, such as a content focused approach and to explore personalization solutions that incorporate inclusive design. To address these issues we have adopted the following strategies:

  1. Select a phased approach. In our first phase we looked at eight different disabilities or categories that cut across types of cognitive impairment in terms of severity and brain function. Although some user needs might not have been identified in this phase, this approach made the work involved practical and it is likely that most key needs will have been identified. Other cognitive disabilities and emotional disabilities may be included in phase 2 and the current user groups may be re-examined.
  2. Compile user research and literature reviews on the selected disability groups. These literature reviews mean that key findings are in the public domain and are easily available.
  3. Compile a list of authoring techniques that include the most useful strategies from all the different user group research 
  4. Create testable and widely adoptable sets of success criteria that let authors know exactly what they need to do and when they have completed the task. (This might then be added to WCAG [WCAG20] for cognitive disabilities)
  5. Author a series of issue papers [coga-issue-papers] that explore topics beyond simple content such as security or personalization.
  6. Review the techniques and issue papers to identify the gaps between what is currently supported in accessibility guidelines and in the web architecture and what is needed to enable accessibility for people with cognitive disabilities
  7. Create a roadmap to show how we can fill these gaps.

In addition to this gap analysis we have first drafts of the following accompanying documents: (Note they are works in progress and may change.)

The diagram shows how these need to be integrated to enable accessibility for people with cognitive disabilities

what we are doing as hexagons
Figure 1 Figure 1. Diagram showing user research leading to techniques & WCAG extension, specific issues, semantics for adaptive interfaces and preferences with integration of standards

A roadmap must enable the integration of all the pieces that can make accessibility for people with cognitive disabilities workable. A roadmap must also address the author needs and issues that will help make this work practical. For example: Best practice documents and how to ensure that personalization is practical and testable.

Roadmap
Figure 2 Figure 2 Anticipated Roadmap

The diagram shows what we are anticipating moving towards a roadmap. (Note that this work has yet to be completed.)

Then we can start the process again with phase 2 for additional research and new user groups, possibly including emotional disabilities.

1.1 Importance of This Document

This document is important because enabling people with learning and cognitive disabilities to use the Web and Web technologies is of critical importance to both individuals and society.

More and more, the Internet and the Web have become the main way people stay informed and current on news and health matters; keep in touch with friends and family; and it can provide independence such as convenient shopping etc. People who cannot use these interfaces will have an increased feeling of having a disability and of being alienated from society.

Further, with the advent of the Web of Things, everyday physical objects are connected to the Internet and have Web interfaces. Being able to use these interfaces now is an essential component of allowing people to maintain their independence, stay in the work force for longer, and stay safe.

Consider that the population is aging. The global share of population aged 60 years or over is expected to reach 21.1 per cent by 2050 and is typically higher in developed countries. A majority of people over 60 years old notice a decline in memory and executive function such as an Age Associated Memory Impairment (38.4%), Mild Cognitive Impairment (15.3%) or less frequently, dementia (8.8%). That means more and more people are dependent on others for things that they could do themselves, increasing the crippling cost of care and reducing human dignity.

We therefore invite you to review this draft; and comment and consider how your technologies and work may be affected by these issues.

1.2 People with cognitive and learning disabilities and the Web

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

1.3 Assumptions

There is a huge number of cognitive disabilities and variations of them. If we attempt an analysis of all the possibilities, the job will be too big, and nothing will be achieved. Therefore, we are adopting a phased approach, selecting in phase one a limited scope of eight diverse disabilities, and hope to achieve something useful within that scope. Also note that helping users improve skills, and emotional disabilities, are out of scope for phase one. We anticipate this analysis will continue to a second or third phase where more user groups are analyzed, and the existing analyses are updated with new research and with new technologies and scenarios.

1.4 Maturity of this publication

The first and second sections of this document are an introduction that analyses the current situation and discusses many issues. Although we are expecting more work to be done on these sections, we consider them to be a mature.

Subsequent sections (the roadmap) identifies unmet user needs and proposes way to solve these needs. These sections are not mature and are often incomplete. We are publishing them early to solicit early feedback on the format and the identification of user needs. You can follow our work on this section and see the latest draft from our wiki.

2. Summary of issues and techniques

As discussed above, the task force reviewed different disabilities to identify techniques that supported their using the web. The task force also reviewed issues that went beyond standard Web content, but affected the use of the Web for people with cognitive and learning disabilities.

This section is a summary of these findings. The full reports can be found from our wiki.

2.1 Overview of techniques

Most designers want people to be able to use their site. However designs that might be difficult for some people to use can actually bar people with cognitive and learning disabilities from using the content at all. Typically this happens because content providers may not be familiar with the needs of users having these impairments. We have reviewed multiple user groups as a first phase to identify user needs and challenges that are not fully included in WCAG. From this research we have identified techniques and themes though the techniques that authors need to be aware of (and are not full addressed in WCAG 2.0) The key themes are:

  1. 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 patters. Personalization based on user needs and markup properly annotated with cognitive semantics can help make the symbols and design as familiar to the user as possible.
  2. Prevent the user from making mistakes and make it easy to correct mistakes when they do occur. A good design and use of proven scripts will make errors less likely, but when they do occur the user should know how to correct them, without having to render other data or start from the beginning.
  3. Help the user to refocus and to restore context if attention is lost. Items like breadcrumbs can help orientate the user and help the user restore the context when it is lost. (Making breadcrumbs clickable can also help the user undo mistakes)

Main techniques include:

A full list of the authoring techniques identified can be found on our wiki.

2.2 Summary of technique solutions

To help bridge the gap we propose the following strategies:

1. Construct a full list of techniques.

2. Support an extension to [WCAG] that supports the techniques. This will include:

  1. Writing new WCAG Success criteria and techniques.
  2. Suggesting changes to existing success criteria such as changing the text or the conformance level
  3. Proposing new success criteria when necessary.
(See appendix two for details of the new WCAG Success criteria and techniques.)

As part of this effort it is important to make this guidance as clear and prescriptive as possible, so that author knows what they need to do and when they have met the requirements.

3. Create a new semantics specification to define the associated semantics required for content adaptation.

  1. This could be done via a WAI- ARIA module or a new Cognitive semantics specification
  2. The techniques for adaptation MUST use these semantics
  3. Specify concrete user settings to represent user preferences that can be used to direct a web application on how to modify the content
(See appendix one for details on the proposed semantics.)

4. Define testing criteria to ensure the authors know when they are done.

  1. This may include new rule sets
  2. This may require the creation of a test suite or specification.

5. Support, and when appropriate, enable better personalization and adaption of content to meet our users' needs. This has the following advantages:

  1. It reduces the effort needed by the author. The author will just need to enable personalization, which is easier then working on issues such as simplification and clarity.
  2. Enables author creativity. Ideally an author could create any interface that they wish, but by enabling API's and personalization, our user groups can receive an adapted interface that is suitable for their needs.
  3. Better accessibility and inclusion. Sometimes, especially with these user groups, user needs can conflict. With adaptability and personalization the interface is personalized to the individuals user needs.

See the discussion on personalization below.

2.3 Summary of issues papers

The following sections provide a summary of the issues and solutions. Full versions can be found from our wiki.

2.3.1 Flat design

Since 2013, flat design has become a popular UI design pattern characterized by clean flat areas of color, clear typography and simply iconography.

2.3.1.1 Problem with flat design

Many people can not learn easily new design metaphors (most coga groups) or remember things that they learned (such as people with a Mild Cognitive Impairment or dementia). Without these skills it can be much harder or impossible to:

  • locate a desired items to interact with and
  • know what interaction may do
2.3.1.2 Solutions for flat design
  1. In the authoring techniques and in proposal for WCAG we are recommending that content provide clear visual affordances (See appendix two for details on the proposed semantics.)
  2. In personalization we are adding settings to allow buttons and controls to have clear affordances
  3. In aria or in the native semantics all roles should be identified. (See appendix one for details on the proposed semantics.)
2.3.1.3 Further work for flat design

How to recommend white spaces which can be confusing if over done for people with low visions? How to recommend clear groups

2.3.2 Web security and privacy technologies

For security purposes, web security and privacy introduce intentional barriers to task completion.

2.3.2.1 Problems with security and privacy

Many people (most COGA groups) have memory issues that can make copying text, or remembering passwords, difficult or impossible. Other contributing issues include impaired executive function. Difficult security mechanisms often bar people with cognitive disabilities from accessing content or using a service at all.

2.3.2.2 Solutions for security and privacy

We recommend a variety of solutions, which may work independently or jointly with others, such as:

2.3.2.3 Further work for security and privacy

Develop ease-of-use ideas, such as:

  • alternative authentication factors
  • consistent user interfaces
  • plain-language instructions and feedback

2.3.3 User safety

2.3.3.1 Problems with user safety

People with impaired reasoning, attention or memory are particularly vulnerable to all types of cyber crime. Examples of types of criminals active on the internet include:

  • Con-artists or cheats, who misled people into giving them money.
  • Hackers, who may steal identity, information, or money without the user being aware of what is happening.
  • Sexual predators, who use the Internet to identify vulnerable people and exploit them, either online or offline.
  1. All user information must be kept safe, to the fullest extent possible. Any clues that the user has cognitive disabilities (such as a request for a simplified version) should be protected information.
  2. Security should be strong AND easily used by those with cognitive disabilities, such as a biometrics option. For a full discussion see the section on security.
  3. Personalization systems can be designed so that any information implying vulnerabilities are on the user device and are secure. Use of functional requirements can also be a safer alternative to describing user needs in systems such as meta-data. Other systems are addressing this issue and further work should include looking at existing solutions.
  4. A site with a chat option should prevent any exchange of personal information.
  5. Users should be regularly warned to avoid scams.
  6. Getting help and /or reporting something worrying should be extremely easy to do. Users should know they will never be penalized for reporting something.
  7. Users should find it easy to report to the cyber crime fighters in their jurisdiction.
  8. Provide easy to use videos and tips that provide explanations about cyber criminals, how to stay safe, and how to report anything you find odd.
  9. Server side solutions can be employed for finding cyber-criminals, such as analytics.
  10. Advertisements and paid articles should be vetted for reliability. They should be clearly marked as external content in an easy to understand way.
  11. Users should be made aware when they are leaving your site or going to a less trustworthy site, including when following links they have been given by users.
  12. Sites offering sexual content or intended for chats of sexual nature should state that clearly.

2.3.4 Math

2.3.4.1 Problems with math

Numeracy issues can occur due to a range of difficulties, the most severe being the inability to read or understand numbers. It should be noted that different users may find math easer to understand than long text.

2.3.4.2 Solutions for math
  • Move towards digital math that can be extended (not numbers in images)
  • Enable highlighting of sections as they are being discussed
  • Link sections of numbers to extra help that can be read together
  • Enable replacing math sections with words or summaries for users who prefer this.

2.3.5 Multi-modal content delivery

Text, which comprises the vast majority of content on the Web, is difficult to understand by many people (most COGA groups).

Also, use cases include:

  1. Jumping to the relevant part of content (This is typically not supported, making content less usable.)
  2. Finding pieces in the content once focus is lost
  3. Going back a step when something was not understood
  4. Going back and forth between where a term was explained and the content of focus
  5. Multi-modal supplements can aid understanding - such as visual maps and spider diagrams
  6. Too many multi-modal items on a page can make the page confusing or overwhelming
2.3.5.1 Solutions for multi-modal content delivery

Text can be made easier to understand when delivered in different modes. Ideally, people should be able to choose that content is delivered in the mode they comprehend best, such as:

  • Text To Speech
  • Video
  • Text With Contextually-Relevant Images
  • Text with Consistent Icons and Graphics
  • Text Replaced or Augmented by Symbol Sets

Further, video and audio should be navigable, such as:

  1. Having the content structured such that it is clearly identified or signposted (e.g., with a slide that says "step two - remove the old washer" or "step three - put on the new washer")
  2. The structure is navigable (e.g., a person can jump directly to step two)
  3. Keywords are identified, and can be jumped to directly
  4. Enabling bookmarks and annotations (that can be navigated)
2.3.5.2 Further work for multi-modal content delivery

Develop ease-of-use ideas, such as development and/or application of:

  • plain-language standards
  • visual and organizational structures
  • font size and font type

2.3.6 Personalization and User Preferences

This summary pulls together a few different issue papers and addresses them together. They are:
  • User Preferences
  • Adaptable Links and Buttons
  • Symbols for Non-Verbal
  • Personalization
  • Providing graded help
  • Interoperable preference
  • (meta data support - to be added)

Full versions can be found from our wiki.

What it is: Personalization involves tailoring aspects of the user experience to meet the preferences or needs of the user. Technology holds the promise of being extremely flexible and the design of many systems includes the expectation that users will be able to optimize their interaction experience according to their personal preferences or accessibility requirements (needs).

We need personalization because:

  1. Different user needs can conflict.
  2. Learning new design patterns (and widgets) can be confusing - we want to allow users to stick with what works for them.
  3. Extra support can be annoying to people who do not need it.
  4. Making content predictable is necessary for accessibility but can often be considered boring design.
  5. Ability to change levels of complexity (increase or decrease) - As the person's skills improve or decrease over time or context.
  6. Enable content providers to really meet the user needs.

For example, using a familiar design, terms and symbols is key to being able to use the web for people who can not remember new symbols (such as some people with memory related impairments like dementia). However, what is familiar for one user may be new for another. Personalization could include loading a set of symbols that is appropriate for the specific user, ensuring that all users find the design and icons simple and familiar.

(See [coga-user-research] section 3.4.15.3 )

2.3.6.1 Problems with personalization
2.3.6.1.1 Preferences for cognitive disabilities

Typical configurable features include adjustments such as colors, text and icon size, sounds or mouse double click speed. Current preferences tend to focus on physical needs that help the user use the content and not on cognitive needs and preferences that help the user understand the content. Meta data and ontologies for preferences also currently focus on physical accessibility needs. For our purposes we need the ontologies to support issues such as:

  1. Types of Language support – such as non-literal language or simple language
  2. Types of Help available
  3. Types of graphics and symbols
  4. API and add on compatibility, such as to help with filling forms or passwords
  5. Adaptable controls for simple and know interfaces
  6. Simplified content with less options
  7. Features to help the user keep and restore context
2.3.6.1.2 Setting and gathering preferences

People with cognitive disabilities can be become daunted, or worse, completely unable to select their desired preferences. Indeed depending on the individual and the technology being used it may be impossible with a supporter's assistance.

So specific problems for people with cognitive disabilities include:

  1. Too many settings and/or options for each
  2. Not knowing what their preferences are in terms of the available technical solutions
  3. Not being aware of possible solutions

The use of custom templates of default preferences for particular groups of users is one method . Selection a base to immediately provided useful settings across a wide range of products and services as a starting point.

Inferring Preferences is one solution but the technology is not yet mature. Another issue is multiple devices and applications.

There is also a significant risk that, if done badly, user information and vulnerabilities can be exposed, exposing the most vulnerable users at the greatest risk.

Interoperable personalization schemes. Interoperable personalization schemes are where users want or need products and services to be personalized, they would prefer or need this to happen across the widest possible range of products or services. Personalization schemes that deliver this ideal will only succeed if they are standardized and if that standard is adopted by the widest range of product and service providers. However there are many critical issues for any personalization scheme to resolve such as funding and adoption.

Current works in progress are GPII (See [GPII-1] which is compatible with ISO/IEC 24751) and ETSI (see [ETSI-1],[ETSI-2], [ETSI-3], [ETSI-4] )


Another issue is Contextual personalization which includes optimizing the personalization of a product or service is to ensure that the personalization is appropriate for the current context of use. For example, settings that will suit the user of a mobile phone in their office or home will not be well suited to that user when they are driving a car.

Metadata is another related topic. Metadata allows the user to find content that they can use and suites their personal needs and preferences. A lot of work has been done for enabling metadata that helps people with physical disabilities find versions of content that they can use. However the semantics and terms do not support the specific requirements of people with different cognitive disabilities.

2.3.6.2 Solutions for personalization
  1. Promote and support advancements in technologies in these area. For example, our recommending for WCAG will be along the lines of "Use semantics and standardized techniques and that enable the content to be adapted to the user scenario and enable additional support " (See appendix two for details.)
  2. Enable compatibility with standards such as GPII but do not depend on them.
  3. Develop the semantics and terms to support the specific requirements of people with different cognitive disabilities. (See appendix one for details on the proposed semantics.)
  4. Enable simple solutions that are extendable - encouraging more complex solutions in the future, such as having preferences be easily cascaded to allow for contextual personalization and for portability in the future.
2.3.6.3 Further work for personalization
  1. Support in WCAG that encourages support the features of the operating system or standards that enable adaption , such as adding additional success criteria.
  2. Develop supporting techniques so authors know exactly what to do
  3. Encourage or develop the terms or ontology for support for cognitive disabilities so that projects like GPII and ETSI can use them.
  4. Develop Semantics for the content so that personalization systems can know more about the content and enable adaptability of the content
  5. Encourage development of at least one end-to-end solution (critical mass) that makes it practical to develop additional solutions that address specific points in the process.
  6. Ensure any solutions architecture protects the user's privacy, such as client side adaptations and metadata that reflect functional requirements only. We also suggest an additional issue paper on related ethics.
2.3.6.3.1 End to end basic solution

We need standardized terms and supportive syntax that can be linked to associated symbols, terms, translations and explanations for the individual use, possibly via an aria attribute and personal preferences.

For example, assume an author can make it programmatically known that a button is used to send an email. At the user end, the button could be rendered with a symbol, term, and/or tooltips that are understandable for this particular user. It could automatically integrate with F1 help that explains the send function in simple terms. It could be identified with a keyboard short cut that will always be used for send. In addition it could be identified as important and always rendered, or rendered as a large button.

Working examples of how this could be used in practice with user preferences are available Full versions can be found from our wiki. It demonstrates personalization for any use - including people with learning and memory issues

It is made of 4 parts:

  1. JSON files for user setting:
  2. Aria proposal for new syntax: Adaptable Links and Buttons
  3. An HTML page that uses some of the new aria syntax:
  4. Scripts that a web author can use or include that read the user settings in the JSON files and adapt the page for the user needs.

This is only one example way to use the semantics. Others may follow. It is also worth noting that the GPII project is working on making user preferences portable which would also enhance this work.

2.3.6.3.2 Special case

Products for people who are non-verbal often use symbols to help users communicate. These symbols are in fact peoples' language. Unfortunately many of these symbols are both subject to copyright AND are not interoperable. That means end-users can only use one device, and can not use apps or content from a different company. If we enabled mapping to open sets of symbol codes that, in turn, map to open or proprietary symbol sets, then they can be interoperable. At the user end , the user agent can load the symbols that the user knows. Symbol sets might still be proprietary but they would also be interoperable. That means the end user could use them across different devices, or any compatible content or applications.

Our members are working on projects to enable interoperable symbol sets and the semantics that would enable it. Such as (Pseudocode):

<img coga-concept="<a rel="nofollow" href="http://symbo.arosac.org/somepage#girlnode">http://symbo.arosac.org/somepage#girlnode</a>" scr="girlwithbow.gif" />

This will require

  • incorporating this as a technique for WCAG and
  • build the necessary semantic support, for web language such as aria.

2.3.7 Distractions

2.3.7.1 Problems with distractions

Distractions can cause people with cognitive disabilities to lose focus on the current action being performed or draw attention away from the primary content and can be difficult for some users to know how to understand, avoid and/or stop them. Distractions can come in the form of overlays, auto-playing content, animated side-bar content, advertisements, prompts, pop-ups, scrolling or auto-updating content and so on.

2.3.7.2 Solutions for distractions
  • Use personalization options to inform the content provider of accommodations required so the presentation of content can be modified.

For overlays, pop-up or pop-over windows:

  • Avoid using overlays.
  • Ensure overlays are easy to close.
  • Ensure overlay content is accessible and doesn't interfere with other accommodations made for AT interoperability.
  • Allow user to turn off overlays while still providing equivalent information and functionality.

For Advertisements:

  • Animation, audio and video plays only on user request (not automatically).
  • Clearly mark advertisements as such.
  • Avoid overlaying content with advertisements, or auto-close the advertisement and return the user to the content when complete.
  • Make advertisements easy to close.

Notifications:

  • Make notifications easy to dismiss or opt out of.

Application installation prompts:

  • Should be accessible, clear and easy to dismiss.
  • Confirm with the user if user action would open an external website.
  • Inform the user which is more accessible and customizable - the application or the website.
2.3.7.3 Further work for distractions

Form a cross-application and cross-device distraction matrix that manages all distractions in one setting. In conjunction with this there could be a mechanism for the user to select or modify the distraction matrix to allow distractions only from certain users and/or applications.

2.3.8 Voice menu systems

2.3.8.1 Problem with voice menu systems

Voice menu systems and Voice XML are used to develop audio and voice response applications similar to automated telephone menu systems. These systems can cause issues for people with cognitive disabilities who may not have the reasoning skills to understand the instructions or have trouble processing the instructions quickly enough while listening to an array of options to choose from. A person with a cognitive disability may have trouble with short-term memory resulting in the inability to remember the number or verbal response required by the application, or may take a longer period of time to verbalize or enter in a response.

2.3.8.2 Solutions for voice menu systems
  • Should have an easily remembered or standard instruction to reach a person for help, such as "0".
  • Describe the option before giving the instruction of what information or option is used to select that option.
  • Use simple terms or language for better comprehension.
  • Pause between phrases, or options, to give time for the user to process the verbal information.
  • Allow more time for the user to provide a response.
  • Provide options for the user to slow down the speech, increase pauses, and allow the user to request more time to respond.
  • Make it easy to go back to a previous menu item, preferably in a standard way, such as '9'.
  • Make it easy to recover from errors, without hanging up on the user, causing them to start from the beginning, or giving even more complex instructions/menus.
  • Avoid advertisements, as they are a distraction that can cause the user further confusion and difficulty remembering options.
  • When designing a voice response system as a product, provide examples and advice that demonstrate how to reduce cognitive load.

2.3.9 Online payments

2.3.9.1 Problems with online payments

People with various cognitive impairments can have a variety of difficulties with the online payment systems used in e-commerce. These difficulties range from having trouble understanding the instructions and process to be followed to complete a transaction to issues in providing the necessary personal and financial information to make an online payment. If an online payment system requires a lot of user input for required information, the presentation of the input fields could cause a cluttered look, which can be distracting and make it difficult for the user to process the steps to take to complete the transaction, adding to their frustration and stress. If the online payment system has voiced commands, persons with speech perception issues may not be able to fully understand the instructions to respond appropriately.

2.3.9.2 Solutions for online payments

The solutions are split into five categories as follows:

  • Navigation
    • Standardize any controls, features and navigation in the online payment system for consistency.
    • Keep menus short with clear labels and signs.
    • Provide ways to navigate back step-by-step or start over.
    • Provide prompts and feedback on the user's progress, give appropriate help when an error is encountered.
    • Limit the number of options to lower cognitive overload.
  • Functionality
    • Use CSS to provide the user control of how information is presented, such as: font, font size, line height, spaces between lines of text, the size of click/touch areas, mouse-over highlighting of text, changes of background and text colors.
    • Provide user with list of information they need to have ready prior to using the web payment system.
    • Provide definitions and explanations for technical terms, acronyms, etc. used by the web payment system.
    • Keep alerts and feedback on the screen until the user explicitly dismisses them.
    • Provide search capabilities tolerant of misspellings and typos.
    • For users with low-literacy or processing impairments, include speaking text/narration.
  • Content and Text
    • Use plain language and short, concise sentences.
    • Use appropriate graphics to enhance understanding.
    • Place critical content "above the fold" to avoid scrolling, if possible.
    • Use bulleted lists and a single idea per paragraph to make more digestible "chunks" of information.
    • Provide meaningful headings.
    • Avoid full justification of text (left and right margins) which can cause large white areas between words.
    • The line length of text should be less than 70-80 characters.
    • Avoid the use of non-literal text and colloquialisms in the text.
    • For people with memory limitations, reduce the standard 7 ± 2 elements per screen to 4 ± 2.
    • Provide the ability for the user to request longer or shorter content to either increase or decrease details provided.
  • Layout
    • Use a consistent layout for each page or step in the web payment system.
    • Streamline the page and reduce any extra information not key to completing the web transaction.
    • Use plenty of white space for an uncluttered look
    • Highlight urgent or important information to be easier to find.
    • Avoid menus that appear or disappear with mouse hover and text that moves or changes.
    • Use high contrast between text and the background.
  • Multimedia
    • As applicable, use typical accessibility techniques: captions, audio description, subtitles.
    • Use sounds to enhance the visual experience, such as auditory feedback to signal a change of state or completion of an action.
    • Avoid animated graphics which can be distracting, or provide controls to allow the user to adjust the speed of the motion.
    • Use graphics and icons as navigation aids, or to indicate progression through the steps for completing a web payment transaction.

3. Roadmap - Tables of User Needs

This section is work in progress for tables format for the coga roadmap and gap analysis. It identifies user needs that are not currently fully addressed by accessibility.

Each table addresses a group of user needs represented by a few related user stories of the form of "As a <role>, I want <goal/desire> so that <benefit>".

The tables show how related user needs can be met though:

Please note that the following sections are incomplete and is a work in progress. (We are publishing it early to solicit early feedback.)

For a latest version see can be found on our wiki.

3.1 Table 1: Authentication

About the user: Many people (most COGA groups) have memory issues that can make copying text, or remembering passwords, difficult or impossible. Other contributing issues include impaired executive function.

Sometimes security and authentication put a barrier between the user and the task that they are doing so that the user can not use the content or service. For example, difficult security mechanisms that require coping or remembering passwords often bar people with cognitive disabilities from accessing content or using a service at all.

This leads to following user stories:

  1. As a user who has memory impairments and often forget passwords I need to be able to use a site without remembering or copying passwords and user names so that I can use this service.
  2. As a user who has weak executive function I need the login process to be simple and not multi step so that I can use it.

Please note that the following sections are incomplete and is a work in progress. (We are publishing it early to solicit early feedback.)

User Needs Content and HTML WCAG New Semantics Personalization Operating System/Other Discussions

I need a method of secure website authentication that I find easy to use.

 NA  

Propose a new Success criteria such as

When there is a barrier between the content and the user that requires additional cognitive function an alternative is provided that does not require additional cognitive function

Techniques should include how to have security that does use passwords or copying such as biometrics and tokens

  NA  We need to capture the type of security that this user can use  Hardware and operating systems could provide the authentication to websites and application - (needs further investigation and risk analysis) Draft for the issue paper can be found on our wiki.

 I need a safe ways to interact online  

    As above        

3.2 Table 2: Context and distractions

About the user: Distractions can cause people with cognitive disabilities to lose focus on the current action being performed or draw attention away from the primary content and can be difficult for some users to know how to understand, avoid and/or stop them.

Once people have become distracted it can be difficult for them to remember what they were doing. This is especially problematic for people with both low attention and impaired memory such as people with dementia.

This leads to following user stories: To do - fill in user stories

User needs

To do: Create table mapping user needs to solutions

3.3 Table 3: Entering data, error prevention & recovery

About the user: Filling out forms and similar tasks can be overwhelming for most people with cognitive and learning disabilities. This includes relatively minor learning disabilities such as dyslexia or attention related disabilities. Many people (most COGA groups) have memory issues that can make copying text, difficult or impossible. Other contributing issues include impaired executive function.

Many people learning disability can not remember numbers such as their post code, Social Security or Credit Card numbers. Many people even need to check their phone number. This makes entering information slow, and they may need to leave their desk or take a break.

Many users find it very difficult to copy information, due to low visual memory or impaired executive function.

This leads to the following user stories:

User Needs

To do: Create table mapping user needs to solutions

3.4 Table 4: Help and support

About the user: To be filled in

This leads to following user stories: To be filled in

User needs:

To do: Create table mapping user needs to solutions

3.5 Table 5: Simple and clear interface

About the user: Many people can not learn easily new design metaphors or remember things that they learned (such as people with Mild Cognitive Impairment (MCI) or dementia. Without these skills it can be much harder or impossible to locate a desired items to interact with and know what interaction may do. The user can feel lost or overwhelmed.

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

This leads to the following user stories: To be filled in

Please note that the following sections are incomplete and is a work in progress. (We are publishing it early to solicit early feedback.)

User Needs Content and HTML WCAG New Semantics Personalization Operating System/Other Discussions
I need symbols that I understand strait away.

The author will need to make sure the content adapts to user personalization settings to meet this need.

For example an open-source script could be included that would read user settings and import the correct symbol

Draft and demo can be found on our wiki.

 The current proposal is to add a success criteria as follows:

Use semantics and standardized techniques and that enable the content to be adapted to the user scenario and enable additional support

Techniques would and using the correct semantics and importing a script that adapts the page

In adding a semantic for the context (what the thing is for) such as

coga-action="undo"

or

coga-destination="home"

and additional landmarks or region such as

role="warning"

User setting will need to address how to handle different contexts such as coga-action="undo" , for example, which symbol to load for this setting.

A mechanism is needed to read the user setting and adapt the page.

taxonomy will be needed of support end values

Taxonomy is needed for use preferences

GPII and ETSI and other standards will need to allow these preferences to be portable.

Issue papers can be found on our wiki.

 
I need to understand the menu terms so that I know where to find things

The author can use simple and well understood terms.

OR

The author will need to make sure the content adapts to user personalization settings to meet this need.

 To be filled in To be filled in To be filled in To be filled in
I can find the controls that I need

Do not rely on people remembering the scroll

I know what are controls

Use of clear affordances

Or use of the proper roles with adaptations according to standardized user preference

New success criteria required

Interactive controls are visually clear or visually clear controls are easily available

  new semantics are not needed but use of roles or native html are needed if presentational are used to meet this user need  

Json easy personalization needs to allow for clear affordances- either setting individual styles for links buttons and other controls Or a universal setting for clear affordances

  clear affordances and settings in the need to be read and interpreted either as at a website, or by the platform. If the platform is not supporting this option then the author needs to supply the option of clear affordances either in the content or as an automatic (reading the JSON for example) or easy to use setting.

Issue papers can be found on our wiki.

To do: Clarify the following user needs and add them to the above table

3.6 Table 6: Familiar interface

About the user: Many people cannot learn easily new design metaphors or remember things that they learned (such as people with Mild Cognitive Impairment (MCI) or dementia. Without these skills it can be much harder or impossible to:

Using a familiar design, terms and symbols is key to being able to use the web for people who cannot remember new symbols (such as some people with memory related impairments like dementia). Therefore the user needs things to be familiar including:

However what is familiar for one user may be new for another. So the interface needs to be familiar to the individual user.

This leads to the following user stories: To be filled in

Discussions

Full versions can be found from our wiki.

Please note that the following sections are incomplete and is a work in progress. (We are publishing it early to solicit early feedback.)

User Needs Content and HTML WCAG New Semantics Personalization Operating System/Other Discussions
I need symbols that are familiar.

The author will need to make sure the content adapts to user personalization settings to meet this need.

For example an open-source script could be included that would read user settings and import the correct symbol

A demo can be found on our wiki.

 The current proposal is to add a success criteria as follows:

Use semantics and standardized techniques and that enable the content to be adapted to the user scenario and enable additional support

Techniques would and using the correct semantics and importing a script that adapts the page

In adding a semantic for the context (what the thing is for) such as

coga-action="undo"

or

coga-destination="home"

and additional landmarks or region such as

role="warning"

User setting will need to address how to handle different contexts such as coga-action="undo" , for example, which symbol to load for this setting.

A mechanism is needed to read the user setting and adapt the page.

taxonomy will be needed of support end values

Taxonomy is needed for use preferences

GPII and ETSI and other standards will need to allow these preferences to be portable.

Issue papers can be found on our wiki.

 

To do: Clarify the following user needed and add them to the above table

To do: Add the above user needs to the table mapping user needs to solutions

3.7 Table 7: Clear and understandable content and text

About the user: To be filled in

This leads to following user stories: To be filled in

User needs for understandable text:

User needs for understandable content:

To do: Make the above user needs into a table

3.8 Table 8: Navigating the system

About the user: Many people (most COGA groups) have memory issues and/or language issues that can make remembering numbers while processing words, difficult or impossible. Other contributing issues include impaired executive function.

Sometimes developers put a barrier between the user and the task that they are doing so that the user can not use the content or service.

This leads to following user stories:

  1. As a user who has memory impairments and weak language processing skills I want to be able to get help without going though a voiceML menu system so that I can set an appointment or find out some information
  2. As a user who has weak executive function. I need the process to get help to be simple and not multi step so that I can use it.
  3. A user can have trouble identifying the right words to say in a voice menu.

Please note that the following sections are incomplete and is a work in progress. (We are publishing it early to solicit early feedback.)

User Needs Content and HTML WCAG New Semantics Personalization Operating System/Other Discussions

I need to find the information I need without deciphering a lot of text or symbols   

  NA  

Propose a new Success criteria such as

When there is a barrier between the content and the user that requires additional cognitive function an alternative is provided that does not require additional cognitive function

Techniques should include how to have security that does use passwords or copying such as biometrics and tokens

  NA      

I need to identify the option I need quickly

  To be filled in  To be filled in  To be filled in  To be filled in  To be filled in  To be filled in
I need simple-to-navigate menu systems needs further investigation
I need simple-to-navigate voice-menu systems

Use the standard 0 to reach a human operator

use best practices

Propose a new Success criteria such as

When there is a barrier between the content and the user that requires additional cognitive function an alternative is provided that does not require additional cognitive function

alternatives for non vocal

Use of standard 0 to reach a human

understanding of different speech patterns

 Issue papers can be found on our wiki.

4. Personalization semantics

The ARIA Working Group is developing Personalization Semantics 1.0 [personalization-semantics-1.0], a vocabulary of terms to indicate personalization preferences to applications which began in the Cognitive and Learning Disabilities Accessibility Task Force.

5. Significant contributors to this document

Boland, Tim
(National Institute of Standards and Technology (NIST))
Cambron, Thaddeus
Invited expert
Cooper, Michael
staff contact- W3C Staff
Dahl, Deborah
W3C Invited Experts
Ding, Chaohai
University of Southampton
Doran, Anthony
Texthelp
Draffan, E.A.
University of Southampton
Katie Haritos-Shea
Knowbility
Knight, Jamie 
Invited expert
Kirkwood, John
Invited expert
Lee, Steve
Invited expert
Mattes, Kurt
Deque Systems, Inc.
Milliken, Neil
British Broadcasting Corporation
Mueller, Mary Jo
IBM Corporation
Pluke, Mike
Invited expert
Rochford, John
Invited expert
Sajka, Janina
W3C Invited Experts
Schwerdtfeger, Richard
IBM Corporation
Seeman, Ayelet
Invited expert
Seeman, Lisa
Invited expert, IBM Corporation

A. References

A.1 Informative references

[coga-issue-papers]
Issue Papers for the The Cognitive and Learning Disabilities Accessibility Task Force (COGA). W3C. URL: https://w3c.github.io/coga/issue-papers/
[coga-user-research]
Cognitive Accessibility User Research. Lisa Seeman-Kestenbaum; Michael Cooper. W3C. 15 January 2015. W3C Working Draft. URL: https://www.w3.org/TR/coga-user-research/
[ETSI-1]
Human Factors (HF); User Profile Management. ETSI et al. EG 202 325. URL: http://www.etsi.org/deliver/etsi_eg/202300_202399/202325/01.01.01_60/eg_202325v010101p.pdf
[ETSI-2]
Human Factors (HF); Personalization and User Profile Management; User Profile Preferences and Information. ETSI et al. ES 202 746. URL: http://www.etsi.org/deliver/etsi_es/202700_202799/202746/01.01.01_60/es_202746v010101p.pdf
[ETSI-3]
Human Factors (HF); Personalization of eHealth systems by using eHealth user profiles (eHealth). ETSI et al. ES 202 642. URL: http://www.etsi.org/deliver/etsi_es/202600_202699/202642/01.01.01_60/es_202642v010101p.pdf
[ETSI-4]
Human Factors (HF); Personalization and User Profile Management; Architectural Framework. ETSI et al. TS 102 747. URL: http://www.etsi.org/deliver/etsi_ts/102700_102799/102747/01.01.01_60/ts_102747v010101p.pdf
[GPII-1]
Global Public Inclusive Infrastructure (GPII). GPII. URL: http://gpii.net/
[HTML5]
HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 28 October 2014. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[personalization-semantics-1.0]
Personalization Semantics 1.0. W3C. URL: https://www.w3.org/TR/personalization-semantics-1.0/
[wai-aria]
Accessible Rich Internet Applications (WAI-ARIA) 1.0. James Craig; Michael Cooper et al. W3C. 20 March 2014. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria/
[WCAG]
Web Content Accessibility Guidelines 1.0. Wendy Chisholm; Gregg Vanderheiden; Ian Jacobs. W3C. 5 May 1999. W3C Recommendation. URL: https://www.w3.org/TR/WAI-WEBCONTENT/
[WCAG20]
Web Content Accessibility Guidelines (WCAG) 2.0. Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. W3C. 11 December 2008. W3C Recommendation. URL: https://www.w3.org/TR/WCAG20/