Cognitive Accessibility Issue Papers

W3C Editor's Draft

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

Abstract

This is a set of papers that describe accessibility issues for users with various cognitive or learning disabilities. Each issue paper takes information from Cognitive Accessibility User Research [coga-user-research] and distills it into a description of the challenges for a specific user group or web usage pattern, and suggests ways to address those challenges. This information informs the Cognitive Accessibility Roadmap and Gap analysis [coga-gap-analysis] in its identification of which solutions remain unmet at this time. The set of issue papers in this publication is not comprehensive and additional ones may be added to future publications of this document.

This document is part of a set of related informative publications from the Cognitive and Learning Disabilities Accessibility Task Force (COGA TF), a joint task force of 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/.

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 June 2017. In-progress updates to the document may be viewed in the publicly visible editors' draft.

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§

2. List of Issue Papers§

3. Personalization and User Preferences§

3.1 Introduction§

What is personalization: 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).

What are user preferences are settings that identify the specifics needs of the individual user. To be effective user preferences should be standardized so that multiple applications can tailor their content to the user needs without each requiring the user to specify preferences.

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 cannot 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 Aging and Dementia [COGA-1] section 3.4.15.3 )

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

This summary pulls together a few different issue papers and addresses them together. They are:

Full versions can be found from our wiki.

The following papers are also relevant to the delivery of personalization solutions:

3.2 Examples of what we may want personalization to do§

We want to be able to add, remove or change content and features as well as address other issues where personalization can be beneficial. The following are some examples of what is needed.

3.2.1 Adding content and features§

We need to be able to add content and feature such as:

  1. extra help;
  2. orientation information such as text that says what you just did (you just selected priority shipping);
  3. text to speech with highlighting;
  4. increase complexity as skills improve.

3.2.2 Removing content and features§

We need to be able to remove or "hide" confusing elements, such as:

  1. extra or secondary features;
  2. "special offers";
  3. adverts;
  4. decrease complexity as skills improve.

Note that all the information can be behind a "more" button or "legal" link. This will mean that all the information is still available - just not overwhelming.

3.2.3 Changing content and features§

We need to be able to change user interface components to ones that the user knows how to use such as:

  1. an “easy use” media player;
  2. standard dialogs, menus and widgets;
  3. standard icons for AAC users;
  4. standard text, buttons and icons.

3.2.4 Addressing key issues§

We need to be able to address key issue such as:

  1. enabling usable security (see XXX);
  2. edding graded help that works with the needs of this user (see XXX ).

3.3 User preferences§

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. Typical configurable features include color, text and icon size, sounds and mouse double click speed. More comprehensive preferences include enabling different input methods such as speech recognition or assistive technology like screen readers. Other preferences such as language or regional conventions also affect the user's interactions.

3.3.1 Challenges of user preferences for people with cognitive disabilities§

People with cognitive disabilities can be become daunted, or worse, completely unable to effectively use preferences to improve their experience on their own. Preference selection is often implemented by providing a range of forms with controls for enabling or choosing options for each preference. These forms can be complex in detail such audio configuration and in size given that some forms are extensive. A specific preference can be hard to locate in control panels with many options even when search and browsing are provided (e.g., Windows control Panel). As a result, some users in this group will be unable set their preferences without assistance.

There are also other potential difficulties after changes to preferences are made. Changes may not be implemented immediately or further action is required for this to happen. It may also be difficult to revert to a previous setting after trailing and rejecting a particular setting.

3.3.2 Templates for preferences§

The use of custom templates of default preferences for particular groups of users is one method by which members of those groups can be immediately provided with potentially useful settings across a wide range of products and services as a starting point. The task for individual users would then be greatly reduced as they would only need to adjust those default settings that did not match their own personal preferences or needs. The ETSI work (see User Profile Management [ETSI-1]) suggests that organizations that represent such groups of users could develop and promote the use of such user profile templates to their client groups.

Selecting "Use typical settings" when installing a program is effectively using a template that defines a well-balanced set of preferences for a typical user. Clicking on one or more check boxes before selecting "Use typical settings" could allow one of two or three alternative templates to be applied. The [ETSI-1] and [ETSI-2] documents listed in the references describe mechanisms for creating, modifying and applying templates.

3.3.3 Inferring preferences §

Commercial services frequently use inference algorithms to infer preferences from user behavior. Such inference methods can also be of value in non-commercial personalization schemes that are solely designed to benefit the user. However, inferred preferences will always be wrong, even if they only fail to capture minor individual quirks. It is therefore important for users that they are able to correct inaccurate inferences.

3.3.4 Managing user preferences §

Another issue is that changes to settings may not take immediate effect, or if they do, it may be difficult to roll back from a setting that was tried out of curiosity but is unsuitable for the user. As a result, 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 without a supporter's assistance. So specific problems for people with cognitive disabilities include:

  • too many settings and/or options for each;
  • not knowing what their preferences are in terms of the available technical solutions;
  • mot being aware of possible solutions.

In fact, many of these problems effect a wide range of users, not just those with cognitive disabilities.

Another issue is Contextual personalization which includes optimizing the personalization of a product or service 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.

3.4 Potential solutions §

3.4.1 Potential solutions for user preferences §

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 User Profile Management [ETSI-1], Personalization of eHealth systems by using eHealth user profiles (eHealth) [ETSI-3], and Personalization and User Profile Management; Architectural Framework [ETSI-4] ).

3.4.2 Potential solutions for personalization §

3.4.2.1 Ways that personalization is currently addressed §
Personalization is currently addressed via many different ways such as:
  1. User plug ins and software such as a text to speak enabled browsers;
  2. Web services that enable text to speech;
  3. Browser options like auto-fill (which can get it wrong and add mistakes);
  4. Add-ons, toolbars or extensions will allow the user to make Stylistic changes;
  5. Extensions like Readability will remove adverts;
  6. Text simplification;
  7. Use of the mobile web version;
  8. Safeguarding and security is currently handled by having standard safety features available for all users - or external products like parental controls (note this is also a limitation because of personalized and advertised content can be confused with standard content);
  9. Haptic feedback (see UltraHaptics: Multi-Point Mid-Air Haptic Feedback for Touch Surfaces [Carter-1]);
  10. Live Chat help (can be intrusive and bad for ADD);
  11. Speech input like Siri or Google Glass;
  12. Widgit's Point software allows users to point to a word and get to a symbol (see Widgit Symbols [Widgit-1];
  13. Symbol support for interoperability:
    1. The Noun Project (icons) (see The Noun Project [Noun-Project-1]);
    2. Max Lundälv (concept coding framework) (se AAC Vocabulary Standardisation and Harmonisatione [[Lundälv-1]];
    3. Arabic symbol dictionary (see Arab Symbol Dictionary for AAC [ECS-1];
    4. ARASAAC symbols;
3.4.2.2 Limitations of current personalization implementations §

The above implementations do not address most what of what we need.

  1. None of the current implementations address all the use cases for people with learning and cognitive disabilities. For example using personalization so that a main stream website can alternative symbol that are familure to a user or group of users.
  2. No way to switch:
    1. to an “easy use” media player;
    2. standard dialogs, menus and widgets;
    3. standard text, buttons and icons;
  3. Many users forget to use their AT or browser options, and want as little complex installations as possible. There is a lack of additional help and support that is useful for Coga groups (allowing further support).
  4. Frames block add-ons from changing CSS via extensions.
  5. Semantic information is not used.
  6. Personalization should allow for user overrides, but author must be able to limit this.
  7. Live Chat help boxes can be intrusive and complicate the page, need role or other semantic term.
3.4.2.3 Adding to ways we can address personalization§
  1. User CSS [CSS-2017] allowing an ARIA [wai-aria] role for extra help to be loaded However, user style sheets are being deprecated.
  2. RDF [rdf-concepts] and RDFA [rdfa-core] . Issues with these solutions include adaptability and whether typical authors will use them correctly and without errors.
  3. Create additional semantics such as mentioned in the issue paper Proposal for Additional Page Semantics. These semantics, as well as element names, landmarks, Indi UI and WAI-ARIA roles can be linked to user preference to enable the interface to be adapted. A demonstration can be found from our wiki.

If there is an output we will need data binding.

3.4.3 Strategies§

  1. Promote and support advancements in technologies in these area. For example, our recommending for WCAG [[WCAG20]] will be along the lines of "Use semantics and standardized techniques that enable the content to be adapted to the user scenario and enable additional support".
  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.
  4. Enable simple solutions that are expendable - 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.

3.4.4 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 [GPII-1] and ETSI [ETSI-1] 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.
  7. To make this truly interoperable the following needs to be standardized:
    1. User preferences that address the needs of people with cognitive and learning disabilities;
    2. Metadata for alternative versions;
    3. Additional semantics in the page.

3.4.5 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. Proposal for new syntax;
  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 [GPII-1] and ETSI [ETSI-1] is working on making user preferences portable which would also enhance this work.

3.4.6 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 cannot 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. This is addressed further in the issue paper on symbols for people who are non-verbal.

4. Web Security and Privacy Technologies§

4.1 Description of the technologies§

Most user interfaces are designed to help users complete tasks. However, web security and privacy technologies intentionally introduce barriers to task completion. They require users to perceive more and to do more to complete tasks. Three examples of these technologies are passwords, CAPTCHA, and 2-Factor Authentication.

4.2 Challenges of security and privacy for people with cognitive disabilities §

Web security and privacy technologies often block people with cognitive and/or physical disabilities who may not be able to:

The scope of the problem is vast because, for examples, people with disabilities:

4.2.1 Memory §

Many people with cognitive disabilities:

  • may have to look at or listen to text several times to copy or type it into a form field;
  • may not recall steps needed to complete a procedure if an authentication session expires;
  • may reuse passwords;
  • may use simple-to-remember passwords, which are easy to guess/determine;
  • may keep passwords insecurely, such as written on pieces of paper;
  • may not recall where they keep passwords (which may be found by people who should not have them).

Some people with cognitive disabilities may not:

  • be able to recall required text, such as a password or a PIN, or remember how to retrieve it;

4.2.2 Executive function §

Many people with cognitive disabilities may not:

  • complete a multi-step procedure for submitting text, such as a password;
  • complete a timed procedure due to slowness in completing all steps;
  • complete a procedure even if provided multiple opportunities to do so;
  • 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:

  • retrieve required text, such as a password or a PIN;
  • determine the purpose of a web security and privacy technology sufficiently or at all.

4.2.6 Perception-processing limitations §

Many people with cognitive disabilities may not:

  • read text at all because of the intentional distortion of it, a CAPTCHA technique;
  • comprehend text that can't be enlarged without additional distortion;
  • understand text spoken in a computerized and distorted voice, a CAPTCHA technique;
  • recognize characters if they do not form words, or are shown in different fonts/styles.

Some people with cognitive disabilities may not:

  • understand the purpose of buttons such as CAPTCHA's "reset", "listen", and "help";
  • recognize functional elements, such as CAPTCHA's buttons, are clickable.

4.2.7 Reduced knowledge §

Some people with cognitive disabilities may not:

  • recognize images, such as symbols or icons, of web security and privacy technologies;
  • comprehend the meaning of rich media designed to be instructive.

4.3 Proposed solutions §

4.3.2 Ease-of-use ideas§

  • Allow alternative authentication factors, such as:
    • location (e.g., user's home or place of employment);
    • presence of a trusted family member or friend, who is detected, for examples, by a wearable biometric device or by a mobile device.
    • could be implemented consistently so that the interface is the same across web sites
  • Develop and use a consistent interface, such as common sets of vocabulary and iconography, across web sites.
  • Offer textual-password alternatives, such as swipe patterns or click-based graphical passwords.
  • Provide security and privacy instructions and policies in plain language.
  • Provide helpful feedback during web-form submission, such as explanations of:
    • why an entered password is insufficient; and/or
    • how to create a password that is easy to remember but hard to guess/determine.
  • Set a high-security privacy option as the default, but ensure it is easy to use.
  • Use a password-keeper app that is accessed biometrically, such as via fingerprint or voice print.

4.3.3 Alternative web security and privacy technologies§

  • Security tokens, some of which are hardware devices, can be used to make authentication easier. Security tokens are used instead of, or in addition to, other forms of authentication such as passwords. Security-token hardware devices:
    • include key fobs, rings, or small keypads;
    • can store and/or generate a digital signature, a PIN, or biometric data;
    • can transmit such data via a USB connector, RFID, Bluetooth wireless, or NFC.
  • Keygen, an element of HTML5, can be used to simplify re-authentication. After a user has completed authentication using keygen, the user will be automatically authenticated for subsequent uses of a web site or service. Thus, there will be no need for a user to re-enter authentication information.
    • Keygen establishes a private-key and a public-key pair.
    • The keygen tag designates a key-pair field in an authentication form.
    • Upon form submission:
      • a private key is encrypted and saved locally; and
      • a public key is signed with the private key, and is sent to the server.
    • In subsequent authentication sessions, the server will either automatically retrieve the private key, or prompt the user to select it.
    • See [html5] 4.10.12 The keygen element.
  • Fast IDentity Online (FIDO), password-free standards for typical and two-factor authentication.
    • FIDO relies upon user authentication based upon a user's device (e.g., phone, tablet, computer).
    • A user's device registers the user, to a server, via a public key.
    • Upon a challenge from the server, the user's device responds with a private key.
    • The device's keys are unlocked by the user biometrically (e.g., fingerprint scanner) or by a button press, not by a password.
  • Spam-free accessible forms, WebAIM, Utah State University, March, 2007.
4.3.3.1 CAPTCHA alternatives§
  • Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web [turingtest]
  • Determine the time difference between when a web form is loaded and when it is submitted. If it is submitted quickly, which may be indicative of a spambot, discard the submission. Otherwise, keep it.
  • CAPTCHA-less Security, Karl Groves, April, 2012.
  • A web-form honeypot that is:
    • an input field
    • hidden using CSS
    • labeled with a field name atypical of forms
    • clearly identified with instructions, for AT users, and for others whom have disabled CSS, not to fill it in
    • checked to determine if something was entered
    • used to reject a submission if something was entered

Note: The web-form honeypot will not work for popular websites because spammers will likely expend the effort to defeat it.

5. Supplementing text with multi-modal content§

5.1 Introduction§

Textual content can be made easier to understand when delivered in different modes to help people with cognitive disabilities. These modes can include the addition of:

5.2 Challenges of text for people with cognitive disabilities §

Difficulty of text comprehension by people with cognitive disabilities ranges from minimal to extreme. They may comprehend most of a web page's textual content, or none at all. These can impact people with impairments of:

5.2.1 Memory §

People with cognitive disabilities may have to:

  • read text several times to aid comprehension;
  • repeat aloud or otherwise reiterate text multiple times to retain it; and/or
  • return to sections when difficulties mean they cannot retain information because content has taken too long to read.

Issues with working memory may affect ability to multi-task so multi-modal approach needs to be used judiciously with user choice depending on the tasks in hand and the setting.

“Good cues for individuals without EMI (episodic memory impairment) can be more subtle and less central to the experience, whereas good cues for those with memory impairment need to cover the important highlights of the experience so that they can re-learn and re-construct the forgotten experience […] Individuals with EMI are more easily cognitively overloaded, which leads to a need for systems to present a smaller number of only the most powerful cues.”

5.2.2 Executive function §

People with cognitive disabilities may not:

  • sufficiently process / understand text as they read it;
  • understand text because they did not understand the text that preceded it; and/or
  • be able to plan which text to read next despite clues such as headings or numbering.

5.2.6 Perception-processing limitations §

Many people with cognitive disabilities may not:

  • comprehend text that can't be enlarged without distortion;
  • recognize characters if they do not form words, or are shown in different fonts or styles, e.g., italics.

5.2.7 Reduced knowledge §

Some people with cognitive disabilities may not comprehend text because:

  • they do not have relevant background knowledge; and/or
  • background concepts are not explained simply.

5.3 Use cases for multi-modal content§

Other 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.4 Ways to enhance text with multi-modal content§

Text is written communication.

Textual content can be provided in a variety of alternative modes / formats as described below. Ideally, people with cognitive disabilities should be able to choose that content is delivered in the mode they comprehend best. This is an important component of the proposed Global Public Inclusive Infrastructure.

Text-to-speech§

Text-to-speech (TTS) is hardware and/or software that produces human speech by a device such as a computer. Most TTS reads text aloud in a synthesized voice. Other TTS converts symbols, such as those employed by augmentative and alternative communication (AAC), into spoken speech.

Many people with cognitive disabilities, such as Dyslexia, may have the capacity to use a screen reader for TTS. However, people with severe cognitive disabilities, such as intellectual disabilities, may require simpler TTS delivery.

A common example is a TTS widget embedded in a website. An alternative is a CSS speech module, as proposed by the W3C. Advantages include that there is nothing to download and install; and learning how to use a TTS widget or a CSS speech module is dramatically simpler than learning how to use a screen reader.

The TTS should be limited to relevant content, and exclude such text as found in menus, footers, and advertisements. Another helpful feature is the visual highlighting of text as it is read aloud. Such features may help people with cognitive disabilities who are overwhelmed even by simple TTS delivery.

Video §

Video is a short film clip of moving visual images with or without audio.

To aid comprehension, video with audio should be captioned and/or have audio description, which provides important information not described or spoken in the main sound track. For example, see "Autistic spectrum, captions and audio description".

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)

WCAG 2.0 Success Criterion References:

Supplement with contextually-relevant images §

An image is a picture, a representation of a visual perception.

User research has shown that text comprehension is significantly enhanced where accompanied by contextually-relevant images. A picture of an object may be easier to recognize than a textual description of it.

Diagrams and charts as visual representations could be helpful for textual descriptions of processes or flows. Employing HTML Canvas, as proposed by the W3C, diagrams and charts could be interactive and have additional descriptions for their parts to aid comprehension.

Supplement with consistent icons and graphics §

An icon is a small image or drawing that commonly represents a function. A graphic is a drawing of a visual perception or an abstract concept, or is otherwise a representation of an object or an idea.

Text accompanied by consistent iconography helps convey meaning, such as by associating discrete textual passages with each other. Similarly, a pie-chart graphic may help convey meaning easier to comprehend than a table of statistics.

Editor's note

What is "consistent" in this context?

Replace or augment by symbol sets §

A symbol is a sign that represents or suggests an idea, an object, an action, or a belief.

Symbol sets can be used for augmentative and alternative communication (AAC) to support people with cognitive disabilities who have severe speech and/or language difficulties. This can include those who may understand speech, but who are unable to express what they wish to say, perhaps because of a physical disability. (It is common for people with cognitive disabilities to also have physical disabilities.) Ideally, interoperable symbol sets could be used to replace or to augment web-based text.

5.5 Ease-of-use ideas§

Text should be written clearly and simply using the following attributes:

Plain language and clear structure will help comprehension of text-to-speech users.

6. Distractions§

A distraction is something that prevents someone from concentrating on a chosen object of attention. When using the Internet distractions may draw the user's attention away from primary content, or from the current action being performed.

Distractions may cause issues for Internet users, especially those who have a cognitive impairment.

6.1 Introduction §

Drawing the user's attention away from primary content can create a range of issues depending on the user's impairment(s). If a user is consuming content and their attention is drawn away this may impact their ability to consume the primary content or complete an interaction (process). If a user is carrying out a complete multistep action (such as form filling) being distracted may cause the user to lose context, thread or position in the action or sequence of actions.

6.2 Source of distraction§

Distraction may come from many sources. Common sources of distraction include:

Overlays: Overlays partially or completely cover the primary content. This makes it impossible to see content until the overlay is removed. Reasons for using an overlay include but are not restricted to help windows, adverts, surveys, paywalls, in page notifications or animations in the site itself. Examples include, but are not restricted to:

Autoplaying Video/Audio: Advertisements, informational notices or a part of site content. May be in sidebars, or headers/footers or even overlaying content. In some cases advertisements may overlay a page for a period of time while the advert plays.

Social Media sidebars. These often animate to draw attention, and while this is effective at drawing attention to an application they take attention away from the user action (reading. form filling etc).

Adwords or similar. These are things that may look like content or links but are actually adverts inserted into the primary content. Distinction between sponsored content and primary content may not be clear to user.

Sponsored content. Advertising content that is not distinguishable from primary content of page. Advertising content of similar topic injected into page may create understandability issues if not able to be removed (through closing) or in a clear and distinct color or ability to remove. Distinct information making content understandable as sponsored may not be present above the fold and therefore sponsored content keys/footnote may not be memorable if not present on page.

App install prompts on mobile devices. These prompts to install an app to access an online service (website etc) rather than use a browser.

Blinking or scrolling text, scrolling and changes in context and changes in content that are not expected or requested by the user can also distract people and make it hard to focus.

6.3 Distractions and people with cognitive disabilities§

Memory §

When attention is drawn away from an action (reading, form filling etc) it breaks the user experience sequence and may result in a loss of context, place or position in the action or sequence of actions for those with impaired memory. This may cause the user to need to re-read content repeatedly, return to a previous page, or restart a sequence such as form filling. This will cause the user to need additional time to complete an action which may cause additional time out issues.

Even one disruption of the user experience by distraction may cause users to abandon a task.

Executive function§

Those with impaired executive skills may have difficulty identifying the source of a distraction. They may have difficulty closing pop-ups, this may impact their ability to use a site with pop-up dialogs (messages, adverts, assistance windows).

Those with impaired executive function may have challenges completing time limited tasks, and as such may have that difficulty exacerbated by distractions, especially those that are difficult to close.

Those with impaired executive function may have difficulty identifying embedded adverts such as Adwords etc, and may assume that they are part of content. This may cause issues where products and commercial messages are interpreted as part of content.

It may be difficult for those with impaired executive function to correctly interpret the purpose of the distraction, to differentiate between adverts, pop-up help windows or actual content.

Those with impaired reasoning may have difficulty closing pop-ups, this may impact their ability to use a site with pop-up dialogs (messages, adverts, assistance windows).

Those with impaired reasoning may have challenges completing time limited tasks, and as such may have that difficulty exacerbated by distractions, especially those that are difficult to close.

It may be difficult for those with impaired reasoning function to correctly interpret the purpose of the distraction, to differentiate between adverts, pop-up help windows or actual content.

Those with attention related difficulties will have those difficulties increased by any distraction from Content focus.

Distraction will increase the time taken to consume content, and for those with significant attention related issues could make a site completely unusable.

Those with language related impairments may not be able to understand the context or purpose of a pop-up or help window.

Those with literacy related impairments may not understand the purpose of a pop-up, or any instructions on how to close or deal with the distraction.

Those with literacy related impairments may need use of Text to Speech software (TTS) or other Assistive Technology (AT). AT functionality may be impaired by overlays.

Perception-processing limitations§

Perception-processing limitations may make it difficult for a user to understand the purpose of a distraction such as a help pop up, or to recognize that the overlay not a part of content. They may have difficulty closing any overlay/pop up or pop over window.

Reduced knowledge§

Reduced Knowledge may prevent a user from identifying the nature of a distraction, and hence dealing with that distraction effectively.

Popups are designed to be hard to close making it impossible for some people to continue their task.

6.4 Proposed solutions§

The following solutions are not tested, and may be accomplished via existing open standards.

6.4.1 Informing content providers of needs§

Inform the content provider of needs and accommodations required. This could be done via a User Agent String, JSON file, Metadata or similar. This would allow content providers to modify how distractions are handled, allowing the front loading of any important information etc.

6.4.2 Overlays, pop up or pop over windows§

Overlays should not be used where possible.

Where unavoidable the purpose of an Overlay should be clear. Overlay should be easily removed without scrolling. The closing mechanism should be clear easy to find, single click and effective. Closing mechanisms should be consistent, standardized and prominent throughout.

Any overlay should be accessible, and should integrate with any existing AT provision already on the site.

Where possible a user should be able to prevent any Overlays. If Overlays contain important information this information should be front loaded so the user does not miss any information.

6.4.3 Adverts§

Adverts should not automatically start playing (if Audio/Visual).

  • Adverts should not Overlay content.
  • Adverts should not present as content. It should be clear that an Advert is an Advert.
  • Adverts should be easily closed.

6.4.4 Notifications§

Notifications - should be easy to dismiss, cancel or opt out of.

6.4.5 Distracting Content (Adwords, blinking text, unexpected changes in content etc)§

Distractions embedded in content should be avoided.

6.4.6 Application install prompts§

Application install prompts should be clear, accessible and easy to dismiss. Confirmation should be obtained from the user before taking the user to any external site.

Where using an application may further impair a user the user should be clearly informed of any limitations, for example where an application is less accessible than the site itself. Similarly if an application is more accessible than the site itself the user should be informed, for example if the application allows more accommodations/customizations than the site itself.

6.5 Integrated solution§

This is a proposal to help people stay focused and productive. It is based on a matrix for distractions at the operating system , browser or cloud level. Currently people can turn off distractions such as Skype, and Facebook, across different devices, and then may forget to turn them back on. This idea manages all distractions by forming a cross application and cross device distraction matrix that manages all distractions in one setting. People and users can be clustered in terms of importance or groups. For example, the CEO and your child's care giver could both be considered critical contacts. So even if they do not feel the message is urgent they can sometimes disrupt the user anyway. Some family members and important colleagues can be in another group, friends and extended family in a third group, system messages from the compliance system can be a different group again.

Dimensions in the matrix can include: Groups of contacts, how urgent the contact feels any message is, and the level of interruptions the user can tolerate at any given time or setting. The user can set how to handle any combination of the above for the level of concentration needed at the time. For example, during normal work hours, messages from important colleagues could interrupt the user, but any other messages would get logged and read when the user has time. In another example the user may be giving a talk and sets the interruption level to critical. Then, only critical messages from key colleagues and family can interrupt. IE: Messages that a critical contact feels is critical and urgent. Default systems can include setting work hours. Optionally, distractions such as news websites could also be limited in low distraction times.

Further pop-ups and similar distractions must be always consistently easy to close and avoid so that all people can continue their task.

7. Voice Systems§

7.1 Introduction§

Voice systems are systems that a user interacts with by listening to spoken prompts from an automated system. The user responds by either pressing keys on a telephone keypad or by speaking (or both). Voice systems are widespread in telephone self-service applications for customer support.

It is worth noting that many crucial systems are dependent on this technology such as emergency notification, healthcare appointment reminders or prescription refilling, and others. Therefore full accessibility needs to be supported.

Voice systems are often implemented with the W3C VoiceXML standard and supporting standards from the Voice Browser Working Group.

See [voicexml20] and [voicexml21]

However, it is important to emphasize that issues of cognitive accessibility for voice systems apply without regard to whether a voice system is implemented using the W3C voice standards or with a proprietary technology.It is impossible for a user to tell what technologies are used in the underlying voice platform, but the usability principles will be the same whatever the underlying technology is.

An example use case may be as follows:

7.2 Challenges for People with Cognitive Disabilities§

Voice technology can be very problematic for people with cognitive disabilities, due to its heavy demands on memory and on the ability to understand and produce speech in real time.

7.2.1 Effect of memory impairments on users' ability to understand and respond to prompts§

A good working memory is essential for using menu-based systems that present several choices to the user and ask them to select one choice, whether by speaking or through a key presss. The user needs hold multiple pieces of transitory information in the mind such as the number that is being presented as an option, whilst processing the terms that follow.

A good short term memory (several seconds) is essential so that the user can remember the number or the term.

Without these functions the user is likely to select the wrong number.

7.2.2 Executive function §

Users need to be able to decide when to act on a menu choice. While a menu is being presented, should they wait to hear more options or should they select a choice that seems correct before hearing all the options?

Limitations of executive function may also cause problems 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.

7.2.3 Effect of impaired reasoning §

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.

7.2.6 Effect of impaired speech and language production functions (for speech-recognition systems)§

The user needs to be able to formulate a spoken response to the prompt before the system "times out" and generates another prompt. In the most common type of speech-recognition system (directed dialog) the user only needs to be able to speak a word or short phrase. However, some systems ("natural language systems") allow the user to describe their issue in detail. While this feature is an advantage for some users because it does not require them to remember menu options, it can be problematic for users with disorders like aphasia who have difficulty speaking.

7.2.7 Effect of reduced knowledge§

The user needs to be familiar with the terms used in the menu, even if they are not relevant to the service options required.

7.3 Proposed solutions §

Human backup§

  1. For users who are unable to use the automated system, it must be possible to reach a human, either in a call center or another operator, through an easy transfer process (that is, not by being directed to call another phone number).
  2. There should be a reserved digit for requesting a human operator. The most common digit used for this purpose is "0"; however, if another digit is already in widespread use in a particular country, then that digit should always be available to get to a human agent. Systems especially should not attempt to make it difficult for users to reach an agent through the use of complex digit combinations. This could be enforced by requiring implementations to not allow the reserved digit to mean anything other than going to an operator.
  3. Other digits similarly could be used for specific reserved functions, keeping in mind that too many reserved digits will be confusing and difficult to learn. Remembering more than one or two reserved digits may be problematic for some users, but repeated verbal recitals of the reserved digits will also be distracting.

User settings§

User-specific settings can be used to customize the voice user interface, 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.
  1. 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.
  2. Timed text should be adjustable (as with all accessible media).
  3. The user should be able to extend or disable time out as a system default on their device
  4. 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.
  5. Timed text should be adjustable (as with all accessible media).
  6. Advertisement and other information should not be read as it can confuse the user and can make it harder to retain attention.
  7. Terms used should be as simple as possible.
  8. Examples and advice should be given on how to build a prompt that reduces the cognitive load
    1. 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"
    2. Example 2: Setting a default for a human operator as the number 0

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:
  1. Pauses are important between phrases in order to allow processing time of language and options.
  2. 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"
  3. 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.
  4. Advertisements and other extraneous information should not be read as it can confuse the user and can make it harder to retain attention.
  5. Terms used should be as simple and jargon-free as possible.
  6. 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.

Considerations for Speech Recognition§

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

Technology-based solutions§

Recent developments in call center technology may be helpful for users with cognitive disabilities.
  1. Visual IVR. When a call comes in on a smartphone, the system can ask the user if they want to switch over to a visual interface which mirrors the voice interface. This allows a user to see the prompts instead of having to remember them.
  2. Adaptive voice interface. This is a technology that is sensitive to the user's behavior and changes the voice interface dynamically. For example, it can slow down or speed up to match the user's speech rate [Adaptive].
  3. Tapered prompts. Best practices in voice user interface design include providing several different prompts for each point in the interaction. The different prompts are used based on the user's behavior. For example, if the user takes a long time to respond to a prompt, a simpler or more explanatory version of the prompt by be used instead of the default.
  4. Human assistance. Although the user interacts normally with the voice system, in case the system is unable to process the user's speech, a human agent acts behind the scenes to perform the necessary processing. This would allow users with a limited ability to speak (whose speech might not be recognized by a speech recognizer) to interact with the system.

Status of these solutions§

Note. The above proposed solutions have been tested for users in the general population and have been shown to improve the usability of voice systems, although the extent to which they have been tested with users with cognitive disabilities is not clear.

Note

Currently VoiceXML does not directly enforce accessibility for people with cognitive disabilities. However, a considerable literature on voice user interface design exists and is in many cases very applicable to cognitive accessibility for voice systems. Developers must become aware of these resources and of the need to design systems with these users in mind.

7.4 References§

  1. [AVIxD] The Association for Voice Interaction Design Wiki
  2. [ETSI 202 076] ETSI ES 202 076 V2.1.1 (2009-06)
  3. [ETSI ETR 096] ETSI ETR 096 Human factors guidelines for the design of minimum phone based user interface to computer services
  4. [Section255] Telecommunications Act Section 255 Accessibility Guidelines
  5. [Adaptive]Adaptive Voice White Paper

8. Online Payments§

8.1 Introduction§

Online payment systems collect information necessary to enable electronic money movements used for but not limited to the purposes of e-commerce purchases, bill payments, person-to-person payments, transferring funds between account holder accounts, and wire transfers. The typical source of funds includes demand deposit accounts (also known as debit accounts) such as a checking or savings account, or a credit account such as a credit card or home equity line of credit. These systems function as a fast and secure electronic alternative to traditional money movement or payment methods such as checks and money orders.

Providers of online payment systems include financial institutions, e-commerce vendors, billers such as utility companies, government agencies, and online payment companies like PayPal, Official Payments, or Visa. A secure online account may or may not be required to use these systems. In addition to functionality, online payment systems provide access to transactions, and in some cases bills as well.

The terms "online payments", "web payments", "online bill payments", and "online transfers" all involve use of a web-based or mobile app interface for the purpose of consumer to business, person to person, or account to account money movements. Although some differences exist, the learning and cognitive disability challenges presented by all of these payment systems are very similar. Therefor, the terms are used synonymously in this paper.

Online payments provide opportunities for people with disabilities to live more independently, however interfaces poorly designed or not designed at all for learning and cognitive disabilities can lead to errant payments and the possibility of significant personal financial hardships. Full accessibility is a necessary part of the solution to prevent unintended, potentially financially burdensome consequences associated with using online payments.

8.2 Use Case§

A person wants to pay for an online purchase during check-out §

This use case assumes the person understands the 'shopping cart' concept and has successfully navigated to the payment starting point. The vendor payment system was developed with HTML.

Challenges for people with cognitive disabilities in online payments:

8.3 Challenges of web payments for people with cognitive disabilities§

While the use of computer technologies could be effective in helping individuals with cognitive disabilities make online payments, the diversity of ability, conditions, and experience of users with cognitive disabilities can create problems in many online payment situations. The sheer number of different types of cognitive disabilities and effects that they can have on users adds to an already complex issue.

Designing accessible web payment systems for users with cognitive disabilities can present some interesting challenges. Certain individuals may have trouble processing language and numbers, deciphering auditory input, and with comprehending spatial orientation. To understand material regarding web payments, a person must be able to identify information and integrate it into meaningful “pieces” or “components”. A person with a brain injury (or other cognitive impairments) may take longer to think and respond to online stimuli. In a web payment system, multiple windows as well as complex or cluttered displays can create distractions and cognitive processing problems. Extended sequential operations can be likewise distracting to those with memory deficit problems. The use of right and left click buttons on a mouse can create difficulties for users with memory, perception or reflex problems.

Individuals with lower literacy may have different reading patterns than high literacy readers when it comes to understanding web payment material; while high literacy readers scan text, people with low literacy may read the text “word for word”. This reading style can create a narrow field of view. Objects and information essential for successfully completing online payments may be missed when they are not directly in the flow of text a person is reading.

Effect of Memory Impairments: Individuals with working memory issues and short term/long term memory issues can have difficulty with navigation and interacting with the basic functionality of an online payment system. They may have trouble remembering information such as a street address or Zip Code, forget to enter required information, or not know where to go next.

Effect of impaired executive function: Individuals with emotional control/self-monitoring issues, task flexibility limitations, planning/organization/execution difficulties, and impaired judgment may find it hard to progress properly through a myriad of tasks in web payments. They may become easily frustrated or give up.

Effect of impaired reasoning: Those having issues with fluid reasoning, mathematical intelligence limitations, seriation/behavioral/comprehension knowledge, and abstraction difficulties may find it hard to recognize patterns and compute numbers in web payment systems.

Effect of attention-related limitations: Persons with selective attention/divided attention issues may have difficulty separating out the important aspects from the irrelevant ones in a web payment transaction. Persons with a limit on sustained attention may not be able to successfully complete all the steps in a web payment transaction.

Effect of impaired language related functions: Individuals with speech perception or speech issues may not be able to recognize or respond intelligently to spoken commands in a web payments system. Those with literacy difficulties may not be able to properly read the instructions for a web payments system, and thus not know what to do.

Effect of impaired literacy related functions: With difficulties in speech perception and/or visual perception, individuals may not be able to read or understand written or spoken commands regarding web payment information. Issues with phoneme processing may make it hard to properly process auditory cues, and cross-model association difficulties may hinder associations of symbols with meanings in a web payment transaction.

Effect of perception-processing limitations: Visual perception (e.g., object recognition, pattern recognition) issues for certain persons may make it difficult to properly perceive the relative locations and meanings of symbols related to web payment. In addition, auditory/speech, motor, and/or tactile perception limitations may hinder use of web payment systems displayed via those modalities.

Effect of reduced knowledge: People with grammar, metaphorical, and/or lexical knowledge limitations could find it hard to interact correctly with web payment systems using those capabilities to provide critical information for understanding the process. Issues in cultural knowledge and base language knowledge (including the use of jargon, idioms, icons, etc.) may also figure into making a web payment properly as intended.

Effect of impaired understanding of behaviors or consciousness: Improper understanding of behavioral norms, social cues, that may be important in successfully completing a web payment may introduce difficulties for certain persons.

8.4 Proposed solutions§

It is important in any proposed solutions to make operational tasks (interacting with a web payment system) as transparent as possible in order for people to focus their attentions on the content related functional aspects of the process. The following solutions support general usability of online payment systems for everyone, in addition to assisting those with cognitive disabilities.

8.4.2 Functionality§

It is desirable to allow the user control of as many aspects of the web payment system as possible. For example, CSS (Cascading Style Sheets) can be used to provide control of how information is presented. A user interface component can be used to change the CSS definitions for font and font size; change the line height or space between lines of text; increase the size of "clickable" areas; allow for mouse over highlighting of text for easier reading; change the background color of a page; and invert colors and increase contrast on the page. This approach can allow a designer to maintain higher level control over design families while allowing a person to control the presentation to suit their individual needs.

  • It is desirable to provide external lists for complex operations for those with memory problems.
  • It is important to identify pre-knowledge necessary for a user to successfully utilize a web payment system.
  • It is desirable to provide definitions and explanations for unusual or technical terms presented in a web payment system (for example, by utilizing the ABBR and ACRONYM tags in HTML as appropriate).
  • In a web payment system, it should be ensured that alerts and feedback remain on a screen until a user explicitly removes them.
  • It is important to optimize search facilities, and to include tolerance for misspellings and typos.
  • It is essential to ensure that web payment systems are compatible with screen readers and other assistive technologies.
  • In a web payment system, it is important to include speaking text/narration for users with low-literacy or processing impairments

8.4.3 Content and text§

Proposed solutions should address the three categories of human perception:

Active
Conditioned by a person's knowledge and expectations
Patterned
As the brain attempts to organize information into meaningful patterns
Selective
Picking out the information that stands out to the learner

In particular,

  • Since complex text can create difficulties for users with cognitive impairments, appropriate graphics should be used to help reduce cognitive load and enhance understanding.
  • It is important to use plain language in short, concise sentences (keep it simple) in a web payment system.
  • It is desirable to reiterate information for users with memory problems.
  • A technique may be to use the “newspaper style of writing” – start with a summary then provide the material in an order from most important to least important. It is important to avoid lengthy text or audio, and to prioritize information to ensure that all critical material is at the top half of the page or"above the fold", as well as to avoid the need for scrolling to complete the payment task(s) on a screen, if possible.
  • It is desirable to "chunk" materials in a web payment system – one idea per paragraph.
  • It is desirable to use bulleted lists whenever possible.
  • It is important to use meaningful headings.
  • In a web payment system, line length should ideally not exceed 70-80 characters.
  • It is desirable to include plenty of white space on the page while not creating "rivers of white" caused by full justification.
  • It is desirable to avoid or provide alternatives for non-literal text and colloquialisms in a web payment system.
  • It is good to offer individuals a choice of "long" or "short" content so they can determine and control the level of detail they require when interacting with a web payment system.
  • It may be good to design for working memory limitations (2; 1), and to reduce the standard 7 ± 2 maximum elements guideline for short-term memory to 4 ± 2.
  • A possible technique is to allow the use of unexpected events to possibly help a person retain information.
  • A possible technique is to investigate the use of readability tests, while not all-inclusive, readability tests can provide assistance in maintaining an appropriate level of simplicity for text.

8.4.4 Layout§

Making a web payment system visually interesting and easy to read can make "listening" to that system difficult (due to the use of graphical spacers and tables, which can disrupt the reading order of related text). The use of database driven text and Cascading Style Sheets (CSS) can create web payment systems that satisfy the needs of both visual and aural users, while still making it easy to change information and textual data. Additionally, style sheets help to convey context, allow for graceful degradation, and make it available for a greater number of possible browsers to read the code properly.

  • Consistency is a design goal for most web payment systems. All of the pages in a web payment system should remain as consistent as possible. It is important to ensure that material is well organized on all pages of a web payment system.
  • It is desirable to streamline page design in a web payment system.
  • It is beneficial to highlight urgent or key information in a web payment system. For example, color, highlighting, and HTML or ARIA semantics can be used to aid in selective perception.
  • In web payment system design, it is good to avoid using menus or other text that appears and disappears when the mouse moves over it, and to avoid the use of text that moves or changes.
  • It is extremely desirable to use high contrast between text and background.
  • Reducing clutter and extra material in a web payment system can improve usability and accessibility for those with visual and cognitive disabilities.

8.4.5 Multimedia§

Access techniques (where necessary) involving using multimedia for interacting with web payment systems should include (at a minimum): captioning, audio description, subtitling, and dubbing. However, a variety of new options for multimedia on the internet have presented themselves.

  • It is desirable, since sound and vision may be "complementary modes of information", to use accompanying sounds to help cue a user as to what to do or to enhance a point. It is also desirable to use audio prompts to signal any change of state.
  • It is desirable to present online payment materials in multiple modes, such as including captions to audio and screen readers to enhance text; this can help increase comprehension. It is essential to provide alternate formats for material so that users can choose the format that best suits their needs
  • It may be important in a web payments systems to use fully accessible graphics and recognizable icons as navigation aids.
  • The use of appropriate and clear graphics can help to enhance understanding of materials on a web payments site. However, it is important to not overuse graphics and to avoid animated graphics, as they can be distracting and increase cognitive load. If animations or dynamic displays are being used, it is desirable to include controls that allow a user to adjust the speed and motion.
  • It is desirable to use familiar imagery to aid in memory retention, since there may be a lot of steps involved in progressing through a web payments system.

8.5 Reference Used:§

Cognitive Disabilities and the Web: Where Accessibility and Usability Meet? by The National Center on Disability and Access to Education

Definitions of online payments are at:

9. Online Safety§

9.1 Introduction§

The Internet is not always a safe place. Like life off the Internet, everyone is at risk of having crime being a part of their experience online. Usually referred to as cybercrime these activities, including fraud, terrorism, extortion, harassment and hacking are perpetrated by several types of criminals:

9.2 Safety issues for people with cognitive disabilities§

9.2.1 Hackers§

People with cognitive disabilities may not be able to easily use some of the common security measures used on the Web such as two-factor authentication and safe and unique passwords.

Extra security precautions to increase password strength often make this group more vulnerable to "human error". This can encourage risky behaviour such as keeping a list of passwords on a desk which can be used by anyone who has physical access to the room. Also, when users ask for assistance to complete these security procedures, they can put themselves at high risk of being abused by those they trust to help.

9.2.2 Con-artists §

These cyber-criminals use deception to gain trust and this enables them to negatively influence the behavior of vulnerable individuals. People with cognitive impairment who experience difficulty understanding social cues will likely fail to accurately identify a risky or potentially harmful situation. Those who have difficulty understanding others can act contrary to their own hypothetical actions in a given situation (i.e., mind-blindness) are more trusting and may easily believe false information. Also, people with impaired reasoning, attention or memory may be similarly vulnerable to these situations as they are not especially cognitively equipped to validate presented information.

9.2.3 Sexual predators§

People with cognitive disabilities may be more at risk of being a victim of a sexual crime. This is more likely if:

  • they tend to be unaware of someone using a fake identity or misleading information;
  • they are dependent on care givers and family who they are afraid of disappointing, which makes them susceptible to blackmail;
  • they tend to believe false information and find it harder to validate facts;
  • they are less likely to identify unreasonable requests.

9.2.4 Personalization problems§

Personalization is important, especially as a way to avoid conflict when meeting varying user needs, among many other reasons. However, there is a significant risk that if poorly implemented, user information and vulnerabilities can be exposed. This puts the most vulnerable users of this population at the greatest risk.

9.3 Proposed Solutions§

Safety should be priority when making content accessibile for people with cognitive disabilities extra care should be applied at the same time to keep them safe.

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.

Personalization systems should 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.

9.3.1 Hackers§

Security should be strong and easily used by those with cognitive disabilities, such as a biometrics option. For a full discussion see the issue paper on security.

9.3.2 Sexual predators and con-artists§

  • A site with a chat option should prevent any exchange of personal information.
  • Users should be regularly warned to avoid scams.
  • Getting help and or reporting something worrying should be extremely easy to do. Users should know they will never be penalized for reporting something.
  • Users should find it easy to report to the cyber crime fighters in their jurisdiction.
  • 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.
  • Server-side sulutions, such as analytics, can be employed to find cyber-criminals.
  • Advertisements and paid articles should be vetted for reliability. They should be clearly marked as external content in an easy to understand way.
  • Users should be made aware when they are leaving your site or going to a less trustworthy site, including when fullowing links from other users.
  • Sites offering sexual content or intended for chats of sexual nature should state that clearly.

9.4 Acknowledgments§

Thanks to Crimes against Children Investigations Israel National Cyber Unit for the review.

10. Symbol users with Speech, Language and Literacy Difficulties§

10.1 Introduction§

Voice Output Communication Aids (VOCAs) are devices that have been developed to allow pictures, symbols or words to be used with speech synthesis. The devices may be specialist items with built in systems carrying the symbols. They may also be a generic computer, tablet or mobile with specialist software or apps. The symbols are activated by single or multiple touches, eyes dwelling on a chosen image or manual use of a keyboard or switches. An external input device usually allows for step by step scanning up and down rows and columns of symbols on a grid. Symbols and word choices are personalised to suit the user, representing known objects, actions and happenings.

10.2 Challenges for people with cognitive disabilities using symbols§

The users of Alternative and Augmentative Communication (AAC) based on images or pictographs as symbols tend to have no speech or language, very unintelligible speech or difficulties expressing themselves and/or may need reading support. Individuals may also have severe mobility and dexterity disabilities and/or cognitive impairments. Depending on the skills of the user, the environment and task in hand, symbols may be used to represent a phrase or whole sentence of speech or be made up of individual parts of speech to aid sentence making. Where literacy skills are a challenge the use of online communication becomes an issue due to the lack of accurate symbol to text or text to symbol sets that can be used/translate across all symbol systems.

10.2.1 Memory §

Symbol users may be unable to cope with large amounts of online material. This depends on their ability but may limit the degree to which they can cope with content that is text based.

10.2.2 Reasoning and executive function§

Symbol users may find it hard to plan a route through web pages unless navigation is clear.

They may have other physical and cognitive impairments affecting their understanding and use of navigation controls.

AAC users may also be overwhelmed by the amount of interactions required to complete tasks.

10.2.6 Knowledge§

Symbol users may fail to recognize images, such as symbols or icons that are not in their known set and may lack the ability to use the web as it has been intended, failing to find understandable icons or imagery that provides easy to use navigation or content.

Proposed solutions

The strategy of mapping symbol sets to a common vocabulary may allow developers to incorporate helpful symbols knowing these can be automatically presented to the user in their own symbol language. This schema would also allow symbol users to use their own symbols in an edit box or form knowing it can be recognised by other symbol users with the automatic translation. The primary solutions for the mapping symbols for symbol users could be divided into three different user scenarios. For all these scenarios, the symbols presented to the symbol users could be alternative and adaptive based on the users' preference.

  • Adaptive Symbols in the Web Content;
  • Adaptive Symbols in the User Agent;
  • Adaptive Symbols in the Web Authoring Tools.

Using proposed syntax

One option for interoperable symbol mapping uses the proposed syntax: aria-concept = "uri" to reference target concept URI like the following example.

<img aria-concept="http://wordnet.org/somepage#girlnode" src="girlwithbow.gif"/>

This aria-concept syntax could take advantage of the Concept Coding Framework (CCF). Due to the lack of standardised encoding schemes and common practises, it is difficult to reference to and exchange symbols as an alternative or complement character based texts. Therefore, the CCF provides a common framework to link and map these symbols (currently Blissymbolics and ARASAAC symbols, and eventually other alternative representations) based on the concept coding. For example, the presentation of cat symbol (concept coding: cc-cat-1001) in this scenario would be as follows: for the cat concept: cc-cat-1001, there are different symbols to represent this concept across different symbols providers.

  • If user prefer ARASSC symbols:
    <img aria-concept=" http://www.conceptcoding.org/ontologies/2011/09/01/ConcetpDefinitions#cc-cat-1001" src=" http://www.catedu.es/arasaac/repositorio/thumbs/10/200/9/9881.png"/>
  • If user prefer Bliss symbols:
    <img aria-concept=" http://www.conceptcoding.org/ontologies/2011/09/01/ConcetpDefinitions#cc-cat-1001" src=" http://www.symbolforwindows.eu/images/Bls_cat.gif"/>
  • or other symbols

Mapping symbols

In order to map the symbols from different dictionaries, one of the approaches could be the use of an ontology and Semantic Web technologies to enable interoperability of symbols datasets.

An ontology is a formal specification of a shared conceptualization. In Semantic Web, a vocabulary can be considered as a special form of (usually light-weight) ontology, or sometimes also merely as a collection of URIs with a (usually informally) described meaning. Linked Data is a term used to describe a recommended best practice for exposing, sharing, and connecting pieces of data, information, and knowledge on the Semantic Web using URIs and RDF (The Resource Description Framework, W3C recommend metadata data model). The Concept Encoding Framework Working Group provides the multilingual and multi-modal lexical ontology (The Lexicon Model for Ontologies of the CCF to be made available in a Linked Open Data (LOD) format. It also allows users to search symbols based on different concepts and metadata, such as language, symbol datasets, localization. The following example demonstrates using the RDFa to represent the mapping between symbols based on concept coding.

  • The ARASAAC monitor symbol:
    <div xmlns="http://www.w3.org/1999/xhtml" prefix=" rdf:http://www.w3.org/1999/02/22-rdf-syntax-ns# ccf: http://www.conceptcoding.org/Ontologies/2014/07/ccf-owl-ns# rdfs: http://www.w3.org/2000/01/rdf-schema#">
    <div typeof="ccf:RepresentationItem" about="http://www.conceptcoding.org/ontologies/2011/09/01/ArasAssistiveOntologgy#ARAS274521001">
    <div property="ccf:example" content=""></div>
    <div rel="ccf:concept" resource="http://www.conceptcoding.org/ontologies/2011/09/01/ArasAssistiveOntologgy#ARAS1104789601000"></div>
    <div property="ccf:representationData" content="file:representations/aras/monitor_(2).png"></div>
    <div rel="ccf:representationType" resource="http://www.conceptcoding.org/ontologies/2011/09/01/ArasAssistiveOntologgy#aras"></div>
    </div>
    </div>
  • The concept monitor presented in CCF Linked Data:
    <div xmlns="http://www.w3.org/1999/xhtml" prefix=" df: http://www.w3.org/1999/02/22-rdf-syntax-ns# ccf: http://www.conceptcoding.org/Ontologies/2014/07/ccf-owl-ns# rdfs: http://www.w3.org/2000/01/rdf-schema#">
    <div typeof="ccf:ConceptCode" about="http://www.conceptcoding.org/ontologies/2011/09/01/ConceptCodeDefinitions#cc-monitor-1001">
    <div property="ccf:lemma" content="monitor"></div>
    </div>
    </div>
  • Base Concept:
    <div xmlns="http://www.w3.org/1999/xhtml" prefix=" rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# ccf: http://www.conceptcoding.org/Ontologies/2014/07/ccf-owl-ns# rdfs: http://www.w3.org/2000/01/rdf-schema#">
    <div typeof="ccf:RepresentationItem" about="http://www.conceptcoding.org/ontologies/2011/09/01/BaseReferenceOntology#EN-3721-1001">
    <div property="ccf:example" content=""></div>
    <div rel="ccf:representationType" resource="http://www.conceptcoding.org/ontologies/2011/09/01/BaseReferenceOntology#en"></div>
    <div rel="ccf:concept" resource="http://www.conceptcoding.org/ontologies/2011/09/01/BaseReferenceOntology#BRO-110478960-1000"></div>
    <div property="ccf:representationData" content="monitor, monitors"></div>
    </div>
    </div>
  • Mapping (BRO-114078960-1000 and ARAS-110478960-1000 based on concept cc-monitor-1001)
    <div xmlns="http://www.w3.org/1999/xhtml" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# ccf: http://www.conceptcoding.org/Ontologies/2014/07/ccf-owl-ns# rdfs: http://www.w3.org/2000/01/rdf-schema#" >
    <div typeof="ccf:Mapping" about="http://www.conceptcoding.org/Ontologies/2011/09/01/StandardBridge#9900145925429353419727587434">
    <div rel="ccf:relatesConcept" resource="http://www.conceptcoding.org/ontologies/2011/09/01/BaseReferenceOntology#BRO-110478960-1000"></div>
    <div rel="ccf:relatesConceptCode" resource="http://www.conceptcoding.org/ontologies/2011/09/01/ConceptCodeDefinitions#cc-monitor-1001"></div>
    <div rel="ccf:relatesConcept" resource="http://www.conceptcoding.org/ontologies/2011/09/01/ArasAssistiveOntologgy#ARAS-110478960-1000"></div>
    </div>
    </div>

This approach mainly requires the symbol dataseat providers to publish the symbols and their concepts as "Linked Open Data". As one of four principles in Linked Data, the URI naming for the concepts could provide the target concept link described in the first solution. It could also provide the alternative same concept symbols based on preferred properties, such as localization, language and colour etc.

11. Use of Numbers and Math on the Web§

11.1 Introduction§

Numeracy issues can occur due to a range of difficulties, the most severe being the inability to read or understand numbers. However, the main problems tend to revolve around decoding. When reading measurement an individual with cognitive impairment may understand the concept of 90cms as a length but find it hard to cope with the fact that 0.9m and 900mm are the same length. Individual difficulties include:

  1. understanding what the representation of a number may mean as a concept of:
  2. size
  3. quantity
  4. distance
  5. time
  6. date
  7. temperature
  8. positive/negative
  9. calculation
  10. sequencing
  11. memory
  12. physical access
  13. sensory access
  14. cultural differences
  15. alternative representations

11.2 Specific Categories§

11.2.1 Effect of memory impairments§

Tasks that involve recalling significant amounts of numbers or application including lengthy techniques may be difficult. Examples include, remembering phone and pin numbers, working through an online process such as booking and paying for a train ticket. Shopping online with multiple offers and alternatives.

11.2.2 Effect of impaired executive function§

This involves working memory where individuals may misread and mistype numbers as well as have copying issues. Where numbers look or sound similar these may cause confusion for example, 7 and 9 or 66 and 56 – may be based upon the language and where numbers are read out with no visual cue or may be written with no audio support.

An alternative presentation of numbers may cause problems, so the difference between the calculator keypad, the numbers on a keyboard and a phone pad may result in incorrect numbers being used to unlock or access product services. Cognitive load associated with decoding numbers and symbols should be considered when offering alternative strategies. These alternatives could further exacerbate executive functioning difficulties, for example saying ‘1/5’ as ‘open fraction one over 5 close fraction’ compared to saying ‘one fifth’ – this is to do with the amount said or verbosity.

11.2.3 Effect of impaired reasoning§

If there is an impairment of abstract thinking and reasoning, problem solving and working online with numbers in any way will be impacted upon to such an extent that users will be unable to access arithmetical content, use numerical passwords or cope with decision making based on numerical information such as entering vehicle registration numbers where L and O many be confused with 1 and 0 (one and zero), particularly when using lower case.

Items that need to be added to an edit form in a particular manner such as zip codes or postal codes, dates, time, birthdates etc. may also cause confusion.

11.2.7 Effect of perception-processing limitations§

There are several perceptual difficulties that may impact on numerical ability such sequential processing where comprehension of multiple numerical items in a process may be impacted upon such as addition and subtraction where the order of numbers is crucial. Sequencing difficulties also impact on time and the duration of time or even size of numbers. Auditory perceptual difficulties occur where numbers may appear to be misheard but actually hearing can be good and it is the comprehension that is affected so the number or numerical concept does mean anything. For example the audio CAPTCHA is read out aloud but in the time given the user is unable to process the content.

Visual perceptual difficulties may include spatial and pattern recognition where the user may have problems with diagrammatic representations of numerical and symbolic information. For example extracting information from a graph or diagram, comparing diagrammatic information or where position impacts on the concept – ¾ compared to 4/3.

11.2.8 Effect of reduced knowledge§

Reduced knowledge may occur where an individual has sustained a brain injury and prior understanding of numbers and numerical concepts have been lost. This may result in all the aforementioned issues occurring.

11.2.9 Effect of impaired understanding of behaviours or consciousness§

The abstract nature of numerical information may be impacted on by a lack of understanding the presentation of problems that are inappropriate to the concept of the user’s environment and lifestyle – this may include items such as examples that are given as comparisons such as weighing as much as an elephant – the user is not talking about elephants but making a comparison between heavy and light.

11.3 Proposed Solutions§

Notes on proposed solutions:

  1. Use the NIDER research
  2. Move towards digital math that can be extended (not numbers in images)
  3. Can you link what is being said in the discussion or help with the section of an equation or section so that one is read whilst the other is highlighted?
  4. Enable highlighting of sections as being discussed
  5. Be able link/ associate section of number with extra help outside the page that can be pulled in and read together.
  6. Remove or replace math sections with words or summary

12. Significant contributors to the issue papers §

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

[Carter-1]
UltraHaptics: Multi-Point Mid-Air Haptic Feedback for Touch Surfaces. Carter, T.; Seah, S. A. et al. BristolIG. URL: https://www.youtube.com/watch?v=2QkbVr4J7CM
[COGA-1]
Cognitive Accessibility User Research; Aging and Dementia. W3C. URL: https://www.w3.org/TR/coga-user-research/#aging-and-dementia
[coga-gap-analysis]
Cognitive Accessibility Roadmap and Gap Analysis. W3C. URL: https://w3c.github.io/coga/gap-analysis/
[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/
[CSS-2017]
CSS Snapshot 2017. Tab Atkins Jr.; Elika Etemad; Florian Rivoal. W3C. 31 January 2017. W3C Note. URL: https://www.w3.org/TR/css-2017/
[ECS-1]
Arab Symbol Dictionary for AAC. ECS Accessibility Team. URL: http://access.ecs.soton.ac.uk/blog/symboldictionary/
[ETSI-1]
Reference not found.
[ETSI-2]
Reference not found.
[ETSI-3]
Reference not found.
[ETSI-4]
Reference not found.
[GPII-1]
Reference not found.
[html5]
HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 27 March 2018. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[indie-ui-events]
IndieUI: Events 1.0. James Craig; Michael Cooper. W3C. 30 April 2015. W3C Working Draft. URL: https://www.w3.org/TR/indie-ui-events/
[Noun-Project-1]
undefined. The Noun Project. URL: https://thenounproject.com/about/
[rdf-concepts]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne; Jeremy Carroll. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/rdf-concepts/
[rdfa-core]
RDFa Core 1.1 - Third Edition. Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/rdfa-core/
[turingtest]
Inaccessibility of CAPTCHA. Scott Hollier; Janina Sajka; Michael Cooper. W3C. 3 July 2018. W3C Working Draft. URL: https://www.w3.org/TR/turingtest/
[voicexml20]
Voice Extensible Markup Language (VoiceXML) Version 2.0. Scott McGlashan; Daniel Burnett; Jerry Carter; Peter Danielsen; Jim Ferrans; Andrew Hunt; Bruce Lucas; Brandon Porter; Kenneth Rehor; Steph Tryphonas et al. W3C. 16 March 2004. W3C Recommendation. URL: https://www.w3.org/TR/voicexml20/
[voicexml21]
Voice Extensible Markup Language (VoiceXML) 2.1. Matt Oshry; RJ Auburn; Paolo Baggia; Michael Bodell; David Burke; Daniel Burnett; Jerry Carter; Scott McGlashan; Alex Lee; Brandon Porter; Kenneth Rehor et al. W3C. 19 June 2007. W3C Recommendation. URL: https://www.w3.org/TR/voicexml21/
[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/
[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/
[Widgit-1]
Widgit Symbols. Widgit et al.URL: http://www.widgit.com/symbols/widgit_symbols.htm