Making content usable for people with cognitive and learning disabilities

3.2.2.2.1 How it Helps

This helps many people, including those with poor memory and attention as well as anyone who is easily distracted due to age-appropriate forgetfulness and Attention-Deficit/Hyperactivity Disorder.

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

In another example, a user with Attention-Deficit/Hyperactivity Disorder is looking for information in a video. They can tell by the video title that this video is has the information they need.

3.2.2.2.2 More Details

Headings need to clarify the purpose of this specific page.

When possible, provide information to help users understand how they got to the page. For example: breadcrumbs, clearly indicated on main navigation, highlighting currently selected tab, etc.)

3.2.2.2.3 Examples

Success example: Headings tell me exactly where I am.

Failure example:

• Headings do not clarify the steps in a form;
• Service not available... what service? I have to remember what I was doing to know what service this is about.

3.2.2.2.4 Technical Details

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

coga github: clear purpose

WCAG issue 55

Pull request

3.2.2.3.1 How it Helps

Clearly indicating the current location and progress helps a user who loses focus or gets distracted reorient to their current activity without reading a great deal of content or restarting. Providing information about the steps that need to be completed ensures that a user who may find a process difficult to complete can determine if they can successfully finish.

Examples include:

• someone with dementia loses focus and then cannot remember what they were doing;
• someone with an attention disability gets distracted and then needs to pick up where they left off;
• someone with a learning disability is not sure if this application has too many steps and if they will manage. By seeing they are half-way through they can gauge if they can cope with the entire process.

3.2.2.3.2 Examples

Success example: Using breadcrumbs to indicate the current steps in the process, important choices, as well as past and future steps.

Failure example: Completed steps and choices the user has made are hard to find without relying on memory (example: hidden behind accordions or a previous page).

3.2.2.3.3 Technical Details

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

Clear Purpose

3.2.2.4.1 How it Helps

Using common style and design pattern on controls makes it easier to recognize and understand how to use it. Controls are parts of web pages that do something, e.g. a link, button, checkbox. The goal of these controls is to have someone use them. For example, an older user with age appropriate forgetfulness takes longer to learn new designs. They go to an ecommerce site has boxes around the headers (such as "womens" or "sale") and simple large text for the "add to cart" button. They click on the headings and not on the add to cart. After a few failures they assume they cannot manage it and leave the site.

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

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

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

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

3.2.2.4.2 Examples

Success example:

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

Failure example:

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

3.2.2.4.3 Technical Details

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

Questions raised in the WCAG github issue 36discussion:

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

3.2.2.5.1 How it Helps

Sometimes users are about to press a control and the control moves. As a result, users with slow hand-eye coordination and processing speed may hit the wrong control causing an unwanted action and disorientation. For example, a user prepares to press a button on a video. The orientation changes to landscape and the control moves. Because the user has slow eye tracking or hand-eye coordination, they end up pressing a link to a new video.

Shifting controls and content also can cause cognitive overload and increase mental fatigue. For example, as a user with Traumatic Brain Injury reads content, the content refreshes and an additional article appears above the current content. The article the user is reading moves down. The user becomes disoriented and the application becomes very hard to use or understand.

3.2.2.5.2 More Details

Controls moving unexpectedly includes:

• Links in a list shifting positions
• Orientation changes
• Slow loading of a page that the user thinks is complete

Note that if controls shift because of an action the user, and the user will not be trying to activate a moving control, it is usually not problematic. For example, form controls shift down while a user types text into a text box above the controls or when the user expands a section.

3.2.2.5.3 Examples

Success example:

A loading icon is visible while the page is loading. After the content is finished loading the loading icon is removed and the content stays in the same place.

Failure example:

The user is about to select a phone number to call. As the user is about to touch the phone number, it shifts down. The user presses the wrong phone number and calls the wrong person.

3.2.2.6.1 How it Helps

Controls that affect only one section of a page is confusing. Many users will look again at the content, try and work out what they are supposed to do, and discover the correct controls or scrollbar. However, many people with cognitive or learning disabilities will not be able to work out what they did incorrectly. Others will feel cognitive overload, and will give up as a result. They may assume the application is broken, or that it is just too complicated for them. For all of these users, the application will not be usable.

Having a border or other visual cue around the controls and the relevant page section make it more understandable. If the controls cannot be next to the area they affect, check with user testing that the users with cognitive and learning disabilities find all the page relationships clear and immediately know how to use the controls.

This helps people with cognitive disabilities that impact problem solving skills, those that get overwhelmed when presented with a lot of text, and those with difficulties with more complicated tasks. This can include some individuals with early stages of dementia, people who have had a concussion or a stroke, people with intellectual disabilities, and others. Those impacted may not complete tasks, miss key information, and not return to pages that are complicated to use and understand.

Do not have two scroll bars close together. Some users may find it difficult to determine which one to use with a particular section of content. Instead, use clear visual layout and placement of the scroll bars, break the content into two separate pages, or consider removing unnecessary information from the page.

For example, consider a user living with dementia trying to work out which scrollbar to use if there are more than one embedded in scrollable regions. When they try the wrong scrollbar, they do not get the effect they desire and their content may seem to disappear. If a website has 2 scrollbars; each operates a different section. When users try the wrong scroll bar, they do not get the effect they desire.

3.2.2.6.2 More Details

• Separating Interactive Elements - Place interactive elements like scroll bars and buttons close to the content they can impact. Also, keep interactive elements further from content to which they do not apply. This makes it easier to identify which elements will impact each section of content.
• Examples of clear dividers include high contrast borders or white space. A change in background color can be a clear divider if the contrast is strong enough.
• Sometimes the structure and relationships can be made clear through personalization or user agents and good use of semantics in the code (see WCAG 2.0 SC 1.3.1).
• Pages with scroll bars close together that impact different content areas.

3.2.2.6.3 Examples

Success examples:

• A page includes a scrollbar for one section. The scroll bars look like they are inside the section and there are clear borders around the section so it is clear what content scrolls.
• On a library site, a search box for the whole site is located in the upper right of the site’s main navigation. A second search box searches the library catalog. It is located within a section with a clear border, different background color, and a heading “Library Catalog”. The go button reads “search catalog”.

Failure examples:

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

3.2.2.6.4 Technical Details

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

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

WCAG issue 26 and WCAG issue 39

3.2.2.7.1 How it Helps

Many users, such as those with mild cognitive impairment or dementia, cannot easily learn and remember new design metaphors. Without these skills, it can be much harder or impossible to locate desired items to interact with, and to know what interactions may do. Users can feel lost or overwhelmed.

Because common design elements are repeated often over a long period of use across many sites, users are more likely to recognize the interactions needed.

3.2.2.7.2 More Details

Common design elements, affordances and patterns include:

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

3.2.2.7.3 Getting Started

When deciding pages, select standard components that look and behave the way users expect. Use standard conventions for layout such as the home link in the upper left corner, navigation at the top, search in the upper right, etc. and create an obvious visual hierarchy in the page.

3.2.2.7.4 Technical Details

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

On coga github: familiar-design-a.html

wcag issue 49, pull request 121

On coga github: familiar-design-aa.html

wcag issue 35

3.2.2.8.1 How it Helps

Those with difficulty understanding how to interact with information need to use cues like color, layout and other visual information to help them know where to look, what they should do and how they should complete that task.

For example, an older user with age appropriate forgetfulness takes a long time to learn new designs. When they come to a site, the first page takes time to understand, but then they know what to do on the next page. If the next page is different from the first and also difficult to learn, they become tired and make more mistakes, as they move to a third page the cognitive load becomes too much and they cannot complete the task. This pattern helps by:

• Ensuring a consistent user experience by providing familiarity and building confidence;
• Making it possible to easily use and interact with content;
• Aiding the completion of tasks.

3.2.2.8.2 More Details

This includes:

• Design themes, including heading styles, font choices, symbols, colors, visual appearance of controls, buttons and links should be consistent.
• Headings with the same structural level have the same font and visual style.
• Icons, controls and menu items that have same function and role have the same look and style
• State and focus for elements with similar function and roles have the same style used consistently across a site.
• Layout should be consistent, including position of interactive elements and navigational controls.
• Structure of content and style of presenting information should be consistent throughout, such as organization of block text, images and bullet points.

3.2.2.8.3 Getting Started

Plan the design for your information before adding content. Think about the colors, font choices and areas where text and images will appear.

3.2.2.8.4 Examples

Success examples:

A web page has two submit buttons, both should visually look and function the same way.

All selected radio buttons on the site look the same.

When all links on a page have keyboard focus the focus indicator looks the same.

Failure examples:

3 pages have a submit button, but each one is located in a different place on the page.

There are 6 heading level 2s on a page. 4 are styled using Times New Roman, and 2 use Helvetica.

3.2.2.8.5 Technical Details

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

On coga github: consistent-identification-and-styles.html

On coga github: consistent-identification-and-styles.html

wcag issue 28

On coga github: consistent-cues.html

wcag issue 31

wcag pull request 108

3.2.2.9.1 How it Helps

People who have language comprehension difficulties who may be able to mechanically read but not understand the content or those who have learning and/or reading difficulties may rely on symbols to understand content and navigate to content they need. Symbols also help people who struggle with language and attention to navigate content, including media.

For example, a person with aphasia, has the intellectual ability to understand concepts, but struggles with language. They may be dependent on the use of symbols to browse pages for information.

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

3.2.2.9.2 More Details

• Use personalization semantics;
• Use clear and unambiguous symbols that can easily be seen and made larger;
• Be aware of cultural differences;
• In left-to-right languages, when adding a few symbols to a page place the image to the left of the text.
• When adding multiple symbols to a paragraph or section of text, place the symbols above the text.

3.2.2.9.3 Getting Started

Provide symbols besides key texts, headings, media sections, contact us and help

Find the common symbol used

3.2.2.9.4 Examples

Success example:

A set of instructions where the bullet points are symbols relating to the content within the text.

Failure example:

A page with important instructions and no symbols or images to guide the reader or a very cluttered page of symbols that confuses.

3.2.2.9.5 Technical Details

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

G103: Providing visual illustrations, pictures, and symbols to help explain ideas, events, and processes

Additional Resources:

• More technical details with regards to Symbols.
• How Symbols are used

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

3.2.3.2.1 How it Helps

Confusion can occur when visual hierarchy of information is not immediately apparent to the user. Distinction between levels in content hierarchy may be difficult to understand or perceive due to minimal type size or type weight differences or color differences that are not easily perceived or understood. Furthermore, hierarchy solely dependent on small unique design elements may create confusion.

For example, a drop down accordion menu of additional sub-menu items may not be viewable without understanding it needs to be clicked (or ‘rolled over’) as indicated by a small unique design element.

When opening a web page for the first time, the sub-menus are typically collapsed and their design may make it difficult to even know that they are there. Some users with cognitive disabilities may not guess that they are present, or after seeing one expand by accident, may not generalize that this structure may be present for other items in a menu. Making it easy to notice that there are sub-menu items ensures the user can use this part of your site. An example is a menu without any visual indication that there are sub-menu items.

There are times where how to open the sub-menu item may not be easy for some with cognitive disabilities. If the control to expand a menu item relies on a particular gesture or way of rolling over the area with a mouse, for example, the end user may not figure out how to expand the sub-menu and may abandon the task. An example would be a menu that expands only after moving the mouse over a particular side of the menu text.

3.2.3.2.2 More Details

Small design elements that indicate sub-menu items will be presented that aren’t always readily apparent or meaningful to the user and not universally adopted.

Examples include a chevron (triangle). In different designs it can be either left facing right facing, up facing or down facing depending on state and the unique design standard affecting interpretation of state.

Confusion can occur when a right facing chevron can indicate that more information will be presented on the current page when clicked or it may mean that information is currently being presented, or it may indicate that it takes the user to a new page. Consistent and general best practices should be used to make it understandable to the user.

Furthermore, a series of these nested elements on a long page can create visual hierarchy confusion if dependent solely on interpretation of design elements.

3.2.3.2.3 Getting Started

Create a visually clear hierarchy of in-line information in either a revealed or hidden state. Clearly indicate when text is hidden or when it can be hidden or revealed.

3.2.3.2.4 Examples

An example of consistent “+” sign to show that additional information will be shown when pressed.

Success example:

• The presence of sub-menu items is easy to find because there are triangles next to their menu items.

Failure example:

• No visual indication of sub-menu items is next to the menu item. The only way to discover the presence of the sub-menu item if using a mouse is to move the mouse over the location of the sub-menu item;
• Expanding to view the sub-menu items requires interaction by mouse with a specific area of the menu item, and this area is not visually distinguished.

3.2.3.2.5 Technical Details

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

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

WCAG issue 26

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

WCAG issue 26

3.2.3.4.1 How it Helps

Providing shorter logical segments allows a person to find and review a specific topic. If that person loses concentration or steps away, clear segmentation allows them to easily find their place in the material and start again. This is especially important for educational style content where review is often necessary.

Chunking media also allows for each segment to be given a unique URL and so easily referenced and shared.

Using a clear, logical structure allows users to orient and navigate through the content easily even if they get distracted.

For example:

• Some videos can be naturally organized into chapters or segments
• A podcast can be split into segments rather than a single one-hour recording

3.2.3.4.2 More Details

• Six minutes or less: Media should typically be divided into segments that are 6 minutes or less in duration.
• Navigable: Navigation to each media segment, and a unique, descriptive label must be provided.
• Logical order: Navigation to media segments are presented in a logical order.
• Exception: Media that has no logical breaking points, do not need to be subdivided.

3.2.3.4.3 Examples

• Success example: A 30-minute video is divided into 5 sections, each with a descriptive link to play from that point onwards.
• Failure example: A 30-minute video contains no subdivisions or descriptions of sections, forcing the user to play it from the beginning or guess starting locations within the video.

3.2.3.4.4 Technical Details

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

coga github: clear purpose

WCAG issue 55

Pull request 10

WCAG issue 40

3.2.3.5.1 How it Helps

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

Users who are unfamiliar with the page (or common design patterns) rely on prominent visual styling aids to locate important information.

3.2.3.5.2 More Details

The amount of page visible before scrolling is dependent on a wide range of factors such as physical device size, resolution, pixel density and device setup.

The size of the visible region will be site specific. Where possible, use site statistics to understand what technology users are using and keep this in mind when designing the page.

For example, an elementary school publishes a weekly newsletter with interesting stories about activities and important announcements. Important announcements include early school dismissal. If the newsletter includes less important information before the early school dismissal, a parent who reads slowly may give up before scrolling down to the important information. A clear heading structure can help with this by reducing what needs to be read.

In another example, a user is writing a comment, but the send button is not visible when the view focuses on the text area. As a result, she cannot see how to send her feedback. The company will then not receive any feedback from groups who are not able to find the feedback button.

3.2.3.5.3 Getting Started

Make it easy to find the most important things on the page. Identify key content and its placement early in the design process.

Space at the top of the document is most likely to be visible to users without scrolling. Place key content at the top of the page to give the best experience to the widest range of users.

Consider the most constrained user experience first (e.g., a 240px wide mobile phone) and then design upwards from there in order to account for the widest range of scenarios.

Conducting user testing can identify common use cases and barriers. Adopting responsive development practices can improve the flexibility of the page to a range of different devices and stations.

3.2.3.5.4 Examples

Success examples:

1. A login form is visible without the need to scroll the page.
2. A login form submit button stands out from other links and buttons on the page.
3. Critical health and safety information regarding medication is highlighted and visible without scrolling.
4. Critical health and safety information regarding medication visually stands out from other less important information on the page due to the use of color, boldness and layout.

3.2.3.5.5 Technical Details

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

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

3.2.3.6.1 How it Helps

People with low executive function, impaired memory, and other cognitive and learning disabilities may have difficulty determining what they can do on a site. By calling out important tasks and features, people can more quickly determine whether the site will meet their needs.

For example, a user goes to website to buy the tickets. He sees many reviews and other information but cannot see how to buy the tickets. The user leaves the site.

3.2.3.6.2 More Details

The most important tasks and features are:

• The three tasks the users want to perform
• The three most common tasks (from the users' perspective)
• Tasks that affect the users' health or wellbeing

Usage data can normally identify the most common tasks. Focus groups and surveys are also useful for identifying what the users want.

3.2.3.6.3 Examples

Success example: A library website includes the important tasks directly on the main page. The advanced search box which allows users to search for books in the catalog is located towards the top of the home page and a simple version which allows users to search the site or the catalog is in the main navigation. Important tasks such as signing up for a library card, locating a branch, and reserving a conference room are listed in the main navigation and included on the main page in visually distinct boxes.

Failure example: A library website only includes upcoming events on the main page. Users have to click on a link titled Catalog before they can get to a search box to look for books. Signing up for a library card, locating a branch, and reserving a conference room are included on a page labeled About and are not easily visible from the main navigation.

3.2.3.7.1 How it Helps

Having a search capability allows users to find the content they need even if they cannot find the content using the site menus or other browsing mechanisms. A user can learn how to use search and reuse that skill on many sites.

User studies have shown the aging population tends to rely on search to locate information rather than navigating menus or surfing.

Menu systems and most site navigation require the user to understand the categories that the content provider has created for general use. Users with impaired executive function may be unable to identify the correct categories.

In some cases, users know the correct category via memory, rather than logic. For example, most users remember that the print function is often found under the file menu. Users with impaired memory may not be able to find these menu items based on recall.

Users with impaired short term memory or who are easily distracted may also find navigating a site and going to many pages to look for content is difficult, as they may lose focus and forget what they are looking for.

Search is most useful when it corrects misspellings, finds appropriate or related content and provides suggested auto-corrected versions of the search terms that the user can choose from.

3.2.3.7.2 More Details

Search is less important on small sites where every page is no more than two clicks away from the main page.

3.2.3.7.3 Examples

Success example: A site has a search.

3.2.3.7.4 Technical Details

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

On coga github: search.html

wcag issue 44

3.2.3.8.1 How it Helps

Allowing users to return to a previous point helps prevent mistakes and makes it easy to correct mistakes when they happen.

Examples of mistakes include:

• Touching a control by accident;
• Opening a new link by accident; and
• Closing a window the user intended to keep open.

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

For example, a user is watching a video. They try to increase the volume but touch a different link instead. A new video now loads. The user can press the back button and return to the video they were watching before. They now know they can try and increase the volume and if they make a mistake, they can easily go back and try again.

In another example, the back button did not work as expected, but took them somewhere else (such as the home page). When they try to change the volume or add a comment they often lose the video they were watching and cannot find the way to get back to it. The user now feels they cannot use any of the website's features in case they lose their main content again. They do not expand the screen, change the volume, or leave comments.

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

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

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

3.2.3.8.2 More Details

Options for supporting users going back include:

• Going back steps in a user journey via a clearly labeled action;
• Using clickable breadcrumbs with clickable previous steps and no loss of data;
• Using back and undo features without unwanted data loss;
• Using semantics and personalization to log the steps and return to a step in the process; and
• Reopening a closed window or option.

3.2.3.8.3 Examples

Success example:

The user is watching a video. They touch a control accidentally and pressing back does not take them back to the video

While applying A user accidentally hits the home icon and navigates awayompleting an online form when applying for a job. The user is able to go back through all the screens to be sure they did not misunderstand a section or skip an answer. The user can edit any data they mistyped.

Failure example:

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

3.2.3.8.4 Technical Details

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

Additional Resources:

• More technical details with regards to return
• User needs Table (Table 3 Applicable)
• Background Research Document.
• Personalization Semantics

3.2.3.9.1 How it Helps

Streamlining processes and workflows reduces distractions, mistakes, and mental fatigue. Using short critical paths increases the chance that users with cognitive disabilities can successfully and accurately complete a process or task and navigate a workflow.

3.2.3.9.2 Examples

Success examples:

1. The steps included in the online process to buy movie tickets are:

• Select a movie
• Select the date and time
• Select seats
• Pay
• Print tickets

The movie theater allows the user to view descriptions about the movie and ratings, buy snacks ahead of time, and donate to a charity. These actions, or steps, are not required in order for the user to complete the task of purchasing a movie ticket. Instead of requiring the user make these selections as part of the purchasing process, the user is given these options before the process is started and after it is complete.

2. For the most used function in an app:

• Open the app
• Run the most used function

Failure examples:

1. The steps included in the online process to buy movie tickets are:

• Select a movie
• Select the date and time
• Select seats
• Purchase snacks ahead of time or opt out
• Make a charitable donation or opt out
• Create an account
• Pay
• Print tickets

The movie theater forces users to decide on snacks and making a charitable donation before paying for their tickets. While an opt out option is available, it is somewhat hidden on the screen, particularly on mobile devices, and users often give up when they can’t figure out how to pay.

2. For the most used function in an app:

• Go to the app introduction page, press continue
• Go to the app main page
• Go to a sub page
• Select an option
• Select another option
• Run the most used function

3.2.4.2.1 How it Helps

This benefits many people including those with language impairments, learning disabilities and a poor memory. Using uncommon words can make text and media difficult to understand.

People with language impairments often have a reduced vocabulary and learning new terms is a very slow, difficult process. For other groups, such as people living with dementia, learning new terms is not realistic or possible. Using uncommon words, that they do not already know, will make the content incomprehensible [unable to be understood] and unusable.

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

3.2.4.2.2 More Details

When using uncommon words, provide an explanation by:

• Adding a simple language term in brackets next to it;
• Providing a pop up definition; or
• Using supported mark up (see easylang).

3.2.4.2.3 Getting Started

Start using clear words in headings, labels, navigational elements, instructions, and error messages. This will increase the usability without a large time commitment.

3.2.4.2.4 Examples

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

Your landlord must follow the law.

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

Failure example: Uncommon words and no explanations

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

3.2.4.2.5 Technical Details

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

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

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

On coga github: plain-language-aaa.html pull request 105.

3.2.4.3.1 How it Helps

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

Active voice makes it clear who is supposed to take action. For example, “It must be done.” (passive voice) does not say who must act. “You must do it.” is active voice and clearly states who has the action.

3.2.4.3.2 More Details

• Use other voices or tenses when they will be easier to understand or friendlier.
• In languages where present tense and active voice do not exist or are not the clearest option, use the tense and the voice that are easiest to understand.
• If you are writing about past or future events, do not use the present tense. It will just be confusing.

3.2.4.3.3 Examples

Success example: Plain text in a simple tense

This month your stocks went up.

Failure example: Not plain text

Over the last month, we saw your stocks increasing.

3.2.4.3.4 Technical Details

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

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

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

On coga github: plain-language-aaa.html pull request 105.

3.2.4.4.1 How it Helps

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

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

3.2.4.4.2 Examples

Success Example:

Write clearly.

Failure Example:

Do not write unclearly.

3.2.4.4.3 Technical Details

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

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

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

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

3.2.4.5.1 How it Helps

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

You can explain any non-literal language by:

• Adding a simple language term in brackets next to any non-literal text such as a metaphors and similes;
• Providing a pop up definition; or
• Using supported mark up (see easylang).

In non-text media, explain non-literal as part of the media or include it in a separate file or track.

3.2.4.5.2 More Details

Make sure the meaning remains clear when you replace non-literal text with literal text. Check this when providing literal text in a popup or other alternative.

3.2.4.5.3 Getting Started

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

3.2.4.5.4 Example

Success example: literal text and concrete language

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

Failure example: non-literal text

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

3.2.4.5.5 Technical Details

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

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

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

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

3.2.4.6.1 How it Helps

Step-by-step instructions benefits many people including those with language impairments, learning disabilities or a poor memory.

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

3.2.4.6.2 Examples

Success example:

Separate each step using an If/Then Table

Failure example:

Do not separate each step

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

3.2.4.6.3 Technical Details

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

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

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

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

3.2.4.7.1 How it Helps

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

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

3.2.4.7.2 More Details

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

3.2.4.7.3 Examples

Success example:

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

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

Failure example:

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

3.2.4.7.4 Technical Details

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

• SC Shortname: Manageable blocks - On coga github: chunks.html
• WCAG 2.1 Proposed SC: Manageable blocks (issue 2016 Nov) - WCAG issue 24
• WCAG 2.1 Proposed SC: Manageable Blocks (pull request 2017 Jan) pull request 90

3.2.4.8.1 How it Helps

White space (also called negative space or the background color) reduces clutter and provides definition to content. This gives the viewer a clear overview of a web page. It is used by designers to enhance text and the position of objects on a page.

Using white space aids navigation through a page and helps people read it. It can help the user find important elements on a page. For those with cognitive impairments, white space has been shown to ease reading difficulties and improves understanding of content.

Make sure users can also adjust the amount of white space around objects and text via a web extension or user setting. This supports the ability to identify important elements in the content of a web page.

3.2.4.8.2 More Details

Use clear spacing between letters, words, sentences lines, paragraphs and blocks of text.

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

Note that “white space” is a term that means the background color. It does not always need to be always white!

3.2.4.8.3 Technical Details

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

Use clear spacing between letters, words, sentences, lines, paragraphs and blocks of text.

Text is not fully justified and on coga github: visual-presentation.html, wcag issue 51 and PR number 113.

3.2.4.9.1 How it Helps

For some readers, decoding words, numbers and symbols does not happen automatically and can be demanding on working memory and executive functions. If they find content too demanding they are at risk of losing its meaning and the overall context of the message that is being conveyed. Some users may use assistive technology or personalization tools to reduce the cognitive demands of decoding content. An example would be text-to-speech that reads aloud content allowing for the use of auditory and visual channels.

Users should not need to decipher letters, numbers, and words becuase of formatting or punctuation errors. They should be able to focus on understanding the meaning of the content, especially when they are using assistive technology or personalizing content. It is important that the content is created with these adaptations in mind, to ensure that all users gain the experience you want them to achieve. Content creators should ensure that information is provided in a way that can be read accurately by assistive technology. It may have to be personalized to suit certain users, but this can be achieved when all the elements are accessible.

Use cases:

• “I listen to content so I need it to be announced and phrased correctly so I can understand it.”
• “I listen to content and I hear content read incorrectly or skipped, particularly numbers and symbols.”
• “If text, numbers or symbols are in an unfamiliar layout, I get really confused.”

3.2.4.9.2 More Details

Use punctuation correctly for the language you are writing in, as it will affect how the stress and intonation (known as prosody) patterns from the text are heard, when converted into speech. For example, in English, commas and semicolons will result in a short pause in the speech, whereas a hyphen – will generally be ignored. Question marks, exclamation marks and speech marks can result in changes in intonation, such as a rise in the pitch of the voice.

Avoid the use of Roman Numerals and unfamiliar symbols in text were possible. These can confuse readers and are likely to be read incorrectly by text-to-speech tools. If these symbols are necessary then ensure they are marked up correctly, using techniques such as MathML and abbreviation expansions to provide additional support. Roman Numerals should be presented in upper case if used in isolation as they are likely to be read as individual letters

Be aware that long numbers may be read as single digits or phrased as a single number. This is a particular problem for phone numbers or zip codes. While it is difficult to control exactly how these numbers are read aloud, content creators can help by:

• Displaying the content of the number and using HTML semantics to ensure users and assistive technologies are aware of the number’s purpose. In addition, the following recommendations can assist with improving text-to-speech rendering:
• For phone numbers, using the correct layout for the locality of the phone number and ensure users can select the whole phone number (including area code), so that text-to-speech voices can recognize the format and phrase it correctly.
• For Zip / Postal codes, including state or address information close to the number so that speech voices can expand known abbreviations (such as state names) and listeners can perceive the context.
• When writing long numbers, considering what separators will be familiar to your readers and how it will be read aloud. In general, English speaking countries will use commas between thousands and a period as the decimal separator whereas German and other European countries do the opposite. For example, 1,245 would represent one thousand two hundred and forty-five in English, but one point two four five in German. Text-to-speech output will assume the separators are being used in the format of the language of its voice. If this does not match the content, then listeners can become easily confused. While replacing thousand separators with a space has become a common convention to avoid confusion, it leads to difficulties with text-to-speech with long numbers being read out in a disjointed fashion. For example, 120 034 943 can be read as one hundred and twenty, zero three four, nine hundred and forty-three.

3.2.4.9.3 Examples

Consider how you write dates, because once again the text-to-speech will use the format associated with the language of the voice. A date such as 04/03/2019 will be read as “April 3rd 2019” by a US English voice and “4th of March 2019” by a British English voice. Writing out the month in words can avoid confusion.

3.2.4.9.4 Technical Details

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

• SC Shortname: Clear Text and Voice - On coga github: clear-text-and-voice.html

3.2.4.10.1 How it Helps

Providing an easy-to-understand summary helps many people to quickly decide if the document is relevant to them and their current goal. A high level outline in a few sentences or bullet points is most effective. Abstracts and executive summaries are usually much longer and more detailed as they are designed to summarize the entire document.

For media, summaries help users with short attention span find the exact file they need and jump to correct content.

3.2.4.10.2 More Details

Long Documents have 300 words or more.

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

In media, summaries of each segment should include the main points included in the content. Users should be able to use the summary to uniquely identify the content and know what it will contain.

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

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

3.2.4.10.3 Examples

Success example:

From GOV.UK

Failure example:

In multimedia, the segments are summarized as Chapter 1, part 1. Chapter 1, part 2, etc.

3.2.4.10.4 Technical Details

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

On coga github: help.html

wcag issue 32 and WCAG20-TECHS

3.2.4.11.1 How it Helps

Not all people can understand numbers and numerical concepts.

For example, some people have dyscalculia, a learning disability specifically-related to mathematics. People with dyscalculia have significant problems with numbers and mathematical concepts, but often excel in other intellectual areas.

For example, a user with dyscalculia may have difficulty processing temperature data when presented only in a numeric format. However, if non-numeric alternatives are provided (cold, warm, hot etc.) then they are able to understand the content.

Numeracy issues can occur due to a range of disabilities, the most severe being the inability to read or understand numbers. Other people have challenges with any calculations such as relative sizes or times. 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.

For example, a train schedule has a long list of relative times that they train leaves for different zones on the hour. The user cannot calculate when the next train leaves from their location.

3.2.4.11.2 More Details

Where an understanding of mathematics is not a primary requirement for using this content use one of the following:

• Reinforce numbers with non-numerical concepts, e.g., Very Cold, Cold, Cool, Mild, Warm, Hot, Very Hot.
• Use personalization semantics to supply a non-numerical concepts (when mature ) See Personalization Semantics Wiki and data-numberfree.

Note that other users may find math easier to understand than long text.

Where some math skills are essential for the content:

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

Content that may need extra support include:

1. size
2. quantity
3. distance
4. time
5. date
6. temperature
7. positive/negative
8. calculation
9. sequencing
10. memory
11. cultural differences
12. alternative representation

For these, consider providing a description or representation of what the number means as a concept.

3.2.4.11.3 Technical Details

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

See wcag issue 32

3.2.4.12.1 How it Helps

Reading a sentence phrase by phrase conveys more meaning than reading individual words. Phrases are also easier to comprehend. The more words an individual can process in one glance, the faster they can read, the easier they can understand what’s written, and the more they stay interested. Most people can take in a whole line of text, or more at once. Fixating on many words at a time is necessary for comprehension for many people. A slow reader may read a sentence slowly using 6 to 9 eye fixations, sometimes taking in only a single word (or less) at a time. Adding background noise reduces the number of words readers can fixate on. Removing background noise helps users comprehend more words at the same time.

Also, automatic word recognition is used typically in tandem with phonetics to achieve full reading comprehension. For example, approximately 200 words exist in the English language that must be memorized, and automatically recognized, because they don't fit traditional letter sound patterns, in order to piece together strings of words into sentences. If a user can't recognize these words in 3 seconds, then the text is harder to understand. Background noise can increase the amount of time it takes users to recognize words.

3.2.4.12.2 Examples

Success example:

It is easier to recognize words and process large amounts of text when the content can be easily distinguished from the background.

Failure example:

3.2.4.12.3 Technical Details

None

3.2.4.13.1 How it Helps

Implied content can be difficult for some users because it requires them to:

• Know where to look to get the information, and
• Understand the meaning behind what is being implied.

One example was a research study where people with autism were asked to watch a movie that had a lot of implied communications. They were watching the actors’ mouth, but the information such as that the spoken text was sarcastic was communicated by their facial expressions. When asked about what happened in the movie, some missed the implied communications and the point of the communications.

Another example is a gif used in a social media post that communicates a person’s true feelings about a statement they made in text. Some individuals may not be able to understand the emotion being demonstrated by the person’s body language or facial expression and miss the point the author is trying to make.

When using body gestures, emotion communications, and facial expressions as the only way to communicate something, it is important to include this in another way to ensure all users understand. One way this can be done is through supplementary text.

3.2.4.13.2 More Details

This includes:

• Graphics used alone to identify that something is important, or should be remembered;
• Sarcasm in text; and
• Animations used to add importance or communicate something contrary to the literal meaning of the paired text.

3.2.4.13.3 Examples

Success example:

When writing sarcastic comments in a social media post or email, add supplementary text such as <sarcasm> to help readers understand the intent of your communication. </sarcasm>

Once it is mature you can also use personalization semantics to add non-literal text alternatives.

3.2.4.13.4 Technical Details

None

3.2.4.14.1 How it Helps

Some languages, such as Hebrew and Arabic, have optional vowels and diacritic marks. Without these marks, many words with the same characters have between two (Hebrew) and seven (Arabic) different ways of being pronounced with different meanings. Most readers can read the word based on the context, and use their visual memory to guess the correct pronunciation. People with impaired visual memory, slow readers and screen readers may often guess the incorrect term and/or pronunciation.

For example a user with a language disability is trying to sound out a word. They guess three different pronunciations until they find one that makes sense. Unfortunately, many people with language impairments cannot work out the meaning as words out of context may only provide an idea rather than a specific meaning. Screenreaders often require these characters to speak the correct word.

Note that not all diacritic marks are necessary to pronounce the word correctly. Only letters and diacritic marks that are necessary for the unambiguous pronunciation need to be included.

3.2.4.14.2 Getting Started

In Hebrew add additional Yud (י) and Vav (ו) that enables correct pronunciation.

3.2.4.14.3 Examples

Success example (Hebrew):

אֹמַר /אומר

Failure example (Hebrew):

אמר

Success example (Arabic):

He wrote: كَتَبَ

Books: كُتُبْ

It was written: كُتِبَ

Failure example (Arabic):

كتب

3.2.4.14.4 Technical Details

Words can be deciphered and pronounced to have the correct meaning

3.2.5.2.1 How it Helps

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

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

However, a well-designed form makes it easier to fill in the information and prevent the user from making mistakes by automatically correcting or suggesting the correct date format.

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

3.2.5.2.2 More Details

• Only correct errors if the correction is reliable. Otherwise, if suggestions for corrections are known, give the suggestions to the user.
  • For example, “Did you mean the first of February (01/02) or the second of January (02/01)?"
• Calendars and dates.
  • Calendars should default to the first relevant day. Work calendars should default to first working day of a user's locale;
  • Calendar-based booking systems must prevent the user from booking the return date before the departure date.
• Temperature.
  • Use the default temperature format of location.

3.2.5.2.3 Examples

Success examples:

• Correct errors of the post code being written in the text field with the city or state information;
• The system prevents the user from selecting inappropriate dates and provides provides a simple explanation if the user attempts to do so.

Failure examples:

• The booking form provides two calendars without clear labels and instructions. The form allows the user to select dates without warning as to whether they are possible e.g. flight out on June 1st - flight return May 30th;
• The system allows the user to select inappropriate dates without warning. The calendar merely grays out inappropriate dates which may not be noticed. No warnings are provided.

3.2.5.2.4 Technical Details

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

coga on github: minimize-errors.html

3.2.5.3.1 How it Helps

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

The ability to undo errors helps people with cognitive disabilities safely use forms and reduces the consequences that result from a mistake.

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

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

For people with cognitive disabilities, mistakes being theoretically reversible is not enough. Often the process of reversing a transaction is too complex for them to manage without help. They may not have access to that help meaning they have to live with all the mistakes they have made. In addition, if the process of correcting mistakes is too difficult, users may give up, either losing the transaction or buying unwanted items.

The effect of this happening multiple times is devastating. As a result, many users with disabilities may stop using the Internet for many tasks.

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

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

In some cases, a user may realize that a mistake has been made after the final submission of data. Provide simple language instructions on how to cancel transactions and help the user understand the amount of time needed to cancel a transaction. This makes them less susceptible to scams.

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

3.2.5.3.2 More Details

This typically includes:

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

3.2.5.3.3 Getting Started

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

3.2.5.3.4 Examples

Success examples:

• A summary is provided before submitting important information. The user is able to correct information and return to the summary with a single click.
• Clickable breadcrumbs allow users to see the previous steps, go back, and change them.

Failure examples:

• A summary is provided before submitting important information but the user can't make corrections without losing other data entered.

3.2.5.3.5 Technical Details

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

On coga github: error-prevention-legal.html

WCAG issue 33

pull request 104

3.2.5.4.1 How it Helps

When labels are missing or unclear, users often do not know that the feature is available or what the control is. Although many users can guess what a control is for users with cognitive disabilities or impaired memory or executive function are less likely to be able to remember the design pattern or work out what it is. A clear label, next to the control, means people with cognitive disabilities are more likely to be able to use it.

Similarly, if a label is not next to a control it is confusing for some users. When a label cannot be next to a control, there should be clear visual indicators that clearly, and visibly associate them, so that the control and not belong to a different label. (This will need user testing with learning and cognitive disabilities to ensure it is usable.)

For example, a user living with dementia is using an application. Some controls do not have visual labels. A care giver shows them what the control is for and they can use the application. The next day they try and use it again but cannot remember what the control is for. This application is not useable for them.

In another example, the label disappears when the focus is removed. The user cannot remember what the control is and does not know how to make it reappear.

Labels need to be visible, readable by AT, and be nearby the labeled content

3.2.5.4.2 More Details

Many people with learning and cognitive disabilities use web extension and simple screenreaders. These assistive technologies often do not read ARIA or titles. Until that changes, or an extension displays them, labels should not rely on these attributes for people with learning or cognitive disabilities.

3.2.5.4.3 Examples

Success example:

Label is visible, uses simple common words, and is right next to the control

first name ____________________

Failure example:

Label uses uncommon words that are not easy to understand exactly what is needed.

given name ___________________

3.2.5.4.4 Technical Details

None

3.2.5.5.1 How it Helps

Clear instructions help prevent user errors. This reduces frustration and enhances the user’s autonomy and independence because they can avoid asking for help. This helps anybody with memory issues, people from a different culture, and people on autism spectrum who may miss cultural context.

3.2.5.5.2 More Details

Provide instructions at the start of the process, not simply in an error message.

3.2.5.5.3 Getting Started

In a system with common errors, tackle the most impactful errors first and add guidance as needed.

3.2.5.5.4 Examples

Success examples:

• Provide an image of a passport with the number highlighted to indicate the number that the user should enter.
• Explicitly say which day of the week is the start (e.g., Sunday or Monday) in calendar control when booking a hotel.

Failure examples:

• Request a passport number, but do not indicate which of several numbers is needed. The user is uncertain which is requested.
• Because a site does not clarify the start of week, a user reads the calendar control wrong and books their hotel for wrong day.

3.2.5.5.5 Technical Details

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

On coga github: help.html

WCAG issue 38

3.2.5.6.1 How it Helps

Forgiving form entry processes help prevent user errors up front. This reduces frustration and enhances the user’s autonomy and independence because they can avoid asking for help. This helps anybody with memory issues, people new to culture, and people on the autism spectrum who may miss cultural context.

3.2.5.6.2 Getting Started

For inputs that collect known data types, such as credit card or telephone numbers or geography names, accept common variations on the input format so users don’t have to convert or receive avoidable error messages.

3.2.5.6.3 Examples

Success examples:

• User inputting a financial value can specify the currency used, even if different from the site’s;
• User inputs a credit card number with or without spaces, and the information is accepted;
• User inputs telephone number as written including country code, region code, and number using brackets.

Failure examples:

• User inputs value thinking it is US dollars, but the web site processes in Euros;
• User inputs credit number with spaces only to be told it must include numbers only;
• User inputs telephone number but is told it must include numbers only.

3.2.5.6.4 Technical Details

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

coga on github: minimize-errors.html

3.2.5.7.1 How it Helps

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

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

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

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

This pattern helps people with a variety of disabilities including the following:

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

3.2.5.7.2 More Details

For situations where the absence of a timed event would significantly change the intended functionality of an application (e.g., an auction or another real-time event), it is important to ensure that users with disabilities are properly notified.

A website only times out when sensitive information is given (such as the users credit card information). The sensitive information is asked for at the last stage of the process. The user is warned that once they give the credit card information they should complete the process quickly as the session can time out. After a period of inactivity, the Web page asks the user to press any key for more time. If the user does not respond within 120 seconds, a timeout occurs. However, when the user comes back and logs-in again all the content is back.

3.2.5.7.3 Examples

Success example:

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

3.2.5.7.4 Technical Details

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

On coga github: timed-events.html

wcag issue 14

pull request 116

3.2.5.8.1 How it Helps

• Understand that their actions were processed (e.g., the click did something);
• Prevent uncertainty or doubt regarding the outcome; and
• Remember what they just did.

For example, a user with age-related forgetfulness, may have difficulty remembering how the interface worked. So when they press the send button that may not feel confident that the form was submitted. Feedback, such as a thank you message, will tell them submission occurred and make them feel confident in the process.

During a multi-step task this feedback (user-action feedback) can also assist people with attention or short-term cognitive disabilities remember what they are doing. For example, a user with early dementia may get distracted and then forget exactly where they were in the task. This user-action feedback helps re-orient them. It also helps them avoid leaving a task by reminding them that they are in a process, and where in the process they currently are.

Provide easily-recognizable success or failure feedback with every user action. When possible the feedback should use a consistent and familiar design patterns. For example:

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

3.2.5.8.2 More Details

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

3.2.5.8.3 Examples

Success examples:

• WAI-ARIA states are used to provide state feedback for a toggle button with an animation showing the state (such as a button was pushed).
• Use ARIA-pressed with a visual or a checkbox is checked/unchecked.
• Provide a confirmation message when an email message is successfully sent, or a form is successfully submitted.
• Provide visible and programmatically-determinable information to indicate a new password satisfies security requirements.

Failure example:

• There is no progress-indicator (e.g., breadcrumbs) to communicate completed and current steps in a multi-step process.

3.2.5.8.4 Technical Details

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

On coga github: feedback.html

wcag issue 54

pull request 109

3.2.5.9.1 How it Helps

Users with cognitive disabilities who have trouble with memory, attention to detail or reading comprehension may not be aware of charges unless they are explicitly noted at the start of a transaction task. Terms and conditions can be under a link but charges must be clearly displayed and available in plain language.

Clearly identifying charges at the start of a sale benefits all users. Those with cognitive disabilities will particularly benefit because some groups are less likely to have inferred or guessed the charges would be included. They may not know to look in other locations in the user flow or in another location, for example on the homepage, or on a rates page.

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

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

For example, a person with Executive Function challenges may be trying to order a plane ticket, and not realize that there are extra fees not quoted in the original price, such as taxes, international fees, baggage fees, etc. They may spend hours booking a holiday only to find that they can’t afford it. Alternatively, sometimes they end up purchasing something they cannot afford. And even if they have completed this process in the past, they are not able to bring their experience into future purchases to anticipate the final price. The result is the user loses confidence in their ability to independently purchase a holiday online, may have incurred a debt they are unable to pay, may not attempt again, or only with the help of a hired professional (e.g. travel agent or assistant).

3.2.5.9.2 Examples

Success examples:

• There are no surprise charges or conditions.
• Users are aware of all charges (including hidden fees) and can make an informed decision when they decide to purchase an item and put it in a shopping cart.
• For items that shipping charges vary, the range of shipping charges and the issues that change the rate would be listed, along with a link to where more details can be found. For example, weight and speed of shipping my impact your shipping fees which can be between $4 and $400 depending on location.

Failure examples:

• Final transaction includes unknown charges that result in higher-than-expected total charges.
• Final transactions include conditions of purchase that are not clear to users from the beginning of the task.
• Transactions contain charges or conditions that the user did not know about until they have invested a lot of effort into the sale.
• Final transaction is completed and users are surprised by the total they receive.

3.2.5.9.3 Technical Details

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

On coga github: identify-charges.html

wcag issue 54

WCAG issue 37

3.2.5.10.1 How it Helps

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

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

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

Letting users control when content changes gives users with cognitive disabilities more control over how websites and applications behave. This gives them the opportunity to make choices that enable them to use the content and complete the task.

3.2.5.10.2 More Details

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

Route: Directions and flow such as a GPS route.

Orientation: perspective or view such as map direction.

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

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

3.2.5.10.3 Examples

Success example:

The user can set to change the route if more than a specific amount of time is saved. They can add more information such as how many extra turns are acceptable for saving 5 minutes. When the GPS finds a new route that saves time, the GPS tells the user about the change including how many extra turns were added and how much time will be saved. The GPS asks the user if they want to change the route or if the GPS changed it, the user can go back to the original route in one touch or command.

3.2.5.10.4 Technical Details

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

status.html

3.2.5.11.1 How it Helps

It is vital that users stay safe on the Internet. Information which suggests a user has Dementia or an intellectual disability allows predatory companies and individuals to target that user for scams or other risky activity. For example, a predatory company could send requests for money, saying “you haven’t made your donation” despite the user having made one. Avoid storing information that implies this or, if you do store it, provide strong security for that information.

Users with weak executive functioning are less likely to identify risks correctly so clearly identifying potential risks helps the user stay safe. Add helpful tips for staying safe while using your content and provide help in case of problems.

To help identify risks, we suggest holding research and focus groups with people with cognitive and learning disabilities and to work with people with disabilities to solve potential and existing problems.

For example, many people who cannot copy and paste passwords or use two-step authorization codes ask a caregiver to help them. As caregivers are often just temporary employees, this leaves the user completely exposed. Making passwords longer or requiring users change them regularly increases these unsafe practices and actually makes the application less secure for many people. This type of design error is common because people with cognitive and learning disabilities are left out of the user research and analysis.

3.2.5.11.2 Examples

Success examples:

• Providing alternative login options that have been tested with people who have learning or cognitive disabilities that are approved security techniques, in your jurisdiction, for sensitive data;
• Working with a wide range of people with learning and cognitive disabilities;
• Using industry best practices for storing and securing user information;
• Using consent forms in plain language that have been tested with people with learning and cognitive disabilities to ensure they understand the risks.

3.2.5.11.3 Technical Details

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

On coga github: user-information.html

wcag issue 25

3.2.5.12.1 How it Helps

Most people are familiar with a single set of units that are commonly used for metrics in their location or culture. When presented with metrics in other units they are required to perform a conversion in order to understand the relative magnitude. This will often require using tools such as a calculator or web search engine thus making content less accessible. Provide in line alternatives or an option to switch units that is easily selected, or perhaps based on the user’s location. Common examples are the units used for distance, meters, currency and temperature.

3.2.5.12.2 More Details

Sometimes metrics are commonly declared in a specific unit even when localized alternatives are available. For example, TV or monitor sizes are usually given in inches even when meters are the common unit. However, even, in these cases providing alternatives is still useful as users may not be familiar with the metrics given.

3.2.5.12.3 Getting Started

Provide a mechanism to select a different set of metrics that are more meaningful to the user, or provide common alternatives in the text

3.2.5.12.4 Examples

Success example:

The Eiffel Tower is 1,063 feet (324 meters) tall, including the antenna at the top.

Failure example:

The Eiffel Tower is 1,063 feet tall.

3.2.5.12.5 Technical Details

None

3.2.6.2.1 How it Helps

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

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

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

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

Where standard techniques exist to remove or control distractions, they should be used.

3.2.6.2.2 Examples

Success examples:

• Ap application lets the user decide how they want to be notified about reminders and emails. Users can choose visual reminders and/or sounds, or none. For some users, not having any notifications enables them to focus on a task and then go to their emails or calendar when the task is completed.

Failure examples:

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

3.2.6.2.3 Technical Details

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

On coga github: interruptions.html

wcag issue 47

pull request 98

3.2.6.3.1 How it Helps

Too much text, too many images and too much other content can cause cognitive overload, anxiety and loss of focus. Keeping content down to a small number of important points reduces the clutter, calms the mind and allows for better understanding whilst aiding memory. In particular, it helps those with a short attention span who may leave the page if it appears complex.

3.2.6.3.2 More Details

Avoiding long paragraphs and non-meaningful imagery ensures those with cognitive impairments can concentrate on the important points being made.

Keeping to a few short bullet points and limiting to one or two images related to the main subject areas of a website or service allows the user to choose whether to explore the site further.

The intent of this Pattern is not to clutter the page with unnecessary information but to provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as much of a hindrance as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.

3.2.6.3.3 Examples

Success example:

• Google has one of the simplest yet easiest sites to use and this has been copied by companies such as Trivago with a simple search box and some clear statements followed by some meaningful images as links to other pages.

Failure example:

• A page with too much content, long menus and images set around long paragraphs of dense text does not help anyone but more importantly the message is lost in an overload of information.

3.2.6.3.4 Technical Details

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

WCAG SC 3.3.2

3.2.6.4.1 How it Helps

Some users find distractions difficult especially when the distractions cause them to switch focus mid-task and subsequently return where they left off. For example, a web site may have a large arrow pointing the way to the “book here” link. That emphasizes the start of the booking task, and will help users know when they have started the task.

Often people need to manage their times of concentration so they can focus without interruptions. Thus, prior advice on the time a task takes, it’s complexity or working memory load enables them to better prepare and complete without unintentional abandonment. Furthermore, the provision of a list of required resources before starting the task along with an indication of the number steps left until completion of the task will help avoid unwitting failures.

3.2.6.4.2 Getting Started

Provide an estimate of time required and a list of all required resources at the start of a multi-step task or form. Break the task into steps.

3.2.6.4.3 Examples

Success example:

Before the user begins to book an airline ticket, a message is presented “The average time for booking an airline ticket is 15- 30 minutes. You will need your travel dates, the number of travelers and each travelers' passport to complete this process.”

Failure example:

Another airline does not notify the user that they need their passport. The process times out when the user is trying to find their passport number. The user needs to start over or will abandon the booking.

3.2.6.4.4 Technical Details

None

3.2.7.2.1 How it Helps

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

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

They may also struggle with other steps of login, such as:

• Entering characters in the correct order;
• Entering characters correctly on the first try (resulting in being locked out).
• Finding a PIN;
• Working out puzzles or distorted letters;

They can also give up after getting frustrated with time-limited procedures or presentations of digital security tokens.

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

3.2.7.2.2 More Details

There are many ways to meet this design pattern:

• Use Web Authentication: An API for accessing Public Key Credentials to support inclusive alternatives that do not rely on cognitive function;
• Provide automatic user authentication based upon the use of a trusted device (to which the user has already logged in with their own identity);
• Use biometrics; or
• Use a system the user is already logged in to via third-party authentication services (e.g., OAuth, Facebook, etc.);

Methods of meeting requirements for alternative user authentication would include:

• Clicking a link sent to an email address or a phone number; (Note that this is easy to implement and may be useful for minimal security, such as allowing comments on a blog);
• Logging in by using information present in users' personal documentation, such as the total number of a current account balance, with explanation on how to find this information.

3.2.7.2.3 Examples

Success examples:

• Web Authentication: An API for accessing Public Key Credentials;
• Logging in via Google or Facebook (federated login);
• Two step authentication and Bluetooth link;
• Using a QRC.

Failure examples:

• Using two-step authentication that requires coping;
• Using a password and not allowing pasting into the field.

3.2.7.2.4 Technical Details

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

On coga github: accessible-authentication.html

wcag issue 23

pull request 91

3.2.7.3.1 How it Helps

This allows people with impaired executive function or impaired working memory to login. This is especially important for users who become confused or overwhelmed with multi step processes. For example, a use with traumatic brain injury wishes to use a site for online banking. They can have put their finger on a finger print scanner to authenticate who they are. Other examples included some third party logins such as login with Facebook.

3.2.7.3.2 Examples

Success example:

Allow login with Facebook or use the web authentication protocol and allow single step method that match your security needs.

Failure example:

All login methods involve multiple steps

3.2.7.3.3 Technical Details

None

3.2.7.4.1 How it Helps

This allows people with language and communication disabilities to login without being overwhelmed large blocks of text.

3.2.7.4.2 Examples

Success example:

The user can log in with a third party like Facebook or Google or with the web authentication protocol that allows any easy login option.

Failure example:

Login requires answering security questions. No simple, word free, login alternative is provided.

3.2.7.4.3 Technical Details

None

3.2.7.5.1 How it Helps

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

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

See Voice Menu Systems issue paper for a full discussion.

Why can’t people use complex menus?

• A good short term memory (several seconds) is essential so that the user can remember the number or the term for the menu. Without these functions the user is likely to select the wrong number.
• Many users have a small short term memory. For example, if you can remember 7 letters or items in your head at the same time they may be able to remember one or two. This makes them less likely to manage a menu system correctly.
• For example, a phone menu system (voice ML system) may have an option: "Press 3 for internal services" To use this option the user must remember a digit 3 while figuring out if they need an internal service. Many people cannot do this. It also requires them to press the correct digit.
• When a lot of irrelevant information is given before the correct option, the user may give up. This is especially true if they did not understand all the earlier options and information.

The 0 digit should be reserved for reaching a person. Consistently set the first option for each menu to: "to weight for a person who can help you press 0". This can help everyone reach the support they need.

3.2.7.5.2 More Details

Considerations for Speech Recognition

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

Follow requirements of legislation

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

3.2.7.5.3 Getting Started

Ensure this pattern is included in important systems that affect health, finance, communication, water and government services. Unimportant systems, that do not affect the users' health, safety, money or rights should incorporate as much of this pattern as possible.

3.2.7.5.4 Examples

Success examples:

• Using user interaction dialogs in which the first option "to weight for a person who can help you press 0”;
• Using a user-interaction dialog, such as the standard "0" from any point, where there is easy access to a human operator who can help users achieve their goals;
• Advisory technique: Cueing users to write something that may be useful at a later point, and give them time to do so.

Failure example:

• Long menu systems that make it hard to find a person.

3.2.7.5.5 Technical Details

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

On coga github: task-completion.html

wcag issue 21

3.2.7.6.1 How it Helps

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

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

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

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

Each step in a sequential process must contain the information necessary to allow a user to proceed. They must NOT rely on memory from prior steps. When useful, provide a summary of information from previous steps, and an easy mechanism for traversing the process is available.

3.2.7.6.2 More Details

Follow best practices in general VUI design

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

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

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

User settings

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

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

Considerations for Speech Recognition

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

Follow requirements of legislation

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

3.2.7.6.3 Getting Started

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

3.2.7.6.4 Examples

Success examples:

• Using user interaction dialogs in which the first option "to weight for a person who can help you press 0”.
• Using a user-interaction dialog, such as the standard "0" from any point, where there is easy access to a human operator who can help users achieve their goals.
• Advisory technique: Cue users to write something that may be useful at a later point, and give them time to do so.

Failure examples:

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

3.2.7.6.5 Technical Details

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

On coga github: task-completion.html

wcag issue 21

3.2.8.2.1 How it Helps

The use of complex information, long documents and data in a particular format can present significant barriers to users with cognitive accessibility needs. Users should be able to understand the information and successfully complete described tasks without requiring further external assistance as much as possible. If content is sufficiently complex to cause barrier, it may be inaccessible and then additional supporting help should be provided.

The complexity of information may be inherent in the information itself, for example the language used, the quantity of information, or the subject matter. In this case, it is likely to need careful explanation, organization and presentation for all users to be able to understand without any mistakes, confusion or need of assistance.

In addition, the presentation mode of information, such as a graph, diagram or table, may obscure its meaning through complexity. Here, a supporting description and guided interpretation will highlight the key features the user needs to understand.

Help may be provided in various forms, for example:

• Text "asides" providing explanation and help for diagrams.
• A supporting chart or graph to illuminate text content.
• Video clips that show the tasks being completed in steps.
• A supplemental table – as long as it is not itself complex.
• Popup on hover explanations of keywords - possibly linked to a glossary.
• A flow chart of steps in a process.

3.2.8.2.2 More Details

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

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

3.2.8.2.3 Getting Started

Provide explanatory content for complex information that is important for successful completion of a task including tasks in the real world.

3.2.8.2.4 Examples

Success examples:

• The explanation of a medical procedure and success rate statistics is amplified through the use of an additional text aside, a diagram and a graph.
• The multi-step process for applying for a visa is made easier to use by adding flow chart of all the steps that is always visible. Each step in the flowchart has links to extra help and the current step is clearly highlighted

Failure example:

• A graph and data table of sales figures is shown without any explanation of the key features that relate to the content.

3.2.8.2.5 Technical Details

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

On coga github: help.html

wcag issue 32

pull request 118

3.2.8.3.1 How it Helps

Some people confuse their left with their right and so will may be unable will be unable to use navigation systems. Others may experience difficulty recognizing relative and cardinal directions such as North, South, East, and West,

Providing alternative terms relative and cardinal directions if possible, for example “the driver's side”. This is helped with personalization.

Consider using any standard mechanism for the platform or technologies that provide for personalization of relative and cardinal directions and terms.

3.2.8.3.2 Examples

Success example:

• Simple personalized disambiguation of left and right is always available

Failure example:

• Consistent reference to points of the compass including less well known ones (e.g. N by NE)

3.2.8.3.3 Technical Details

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

On coga github: help.html

wcag issue 32

pull request 118

3.2.8.4.1 How it Helps

Users often find forms and related tasks to be the most complex experience with web sites and can easily become confused, unsure, or even completely lost. Providing extra help can make the difference between being able to successfully complete a task and giving up. This is especially true if any part of the form is complex or provides nonstandard interactions.

Many standard forms controls provide support automatically. For example, many fields can be automatically fill it all in the information using autocomplete or personalization semantics. Then the user will not make mistakes filling it out.

When you require additional fields and nonstandard controls many users will have difficulty filling it in. Many users with disabilities will get the information incorrect or be unable to work out how to complete the task. Often this results in the task being completely abandoned. In other cases, the user asks a care giver for help to complete the form or work the control. In either case, they have not been able to complete the task because of their disability.

3.2.8.4.2 More Details

The standard HTML forms and controls have been carefully specified for maximum usability and accessibility. They are usually understood by users, especially if they are familiar with web interactions. However, users are likely to experience difficulties if the standard form behavior has been altered or completely new controls are provided. Assuming the new behaviors have been carefully designed and user tested, users may still require help in order to successfully use them.

Examples of forms and controls that are likely to require additional help:

• New behaviors like bank sort code fields where there is auto tabbing between the 3 boxes as digits are entered;
• Password fields that require certain character types of characters to be entered;
• Surveys with complex interactions, for example where buttons only appear depending on previous answers;
• Date entry where there could be some ambiguity about the required format;
• custom controls like date pickers.

Help can be provided via various mechanisms, perhaps with an accessible help button next to a nonstandard control.

Sufficient techniques for forms

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

Sufficient techniques for non-standard controls

• Clear and non-ambiguous instructions should be available for non-standard controls.
• Using Personalization semantics for instructions should be available for non-standard controls.

3.2.8.4.3 Examples

Success examples:

• A help button next to date picker provides accessible pop-up help for using the control.
• A form has multiple steps. Users are informed on their progress through the stages.

Failure example:

• A form has complex mechanism for enabling and disabling sections as you scroll or tab between them but no help is provided.

3.2.8.4.4 Technical Details

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

On coga github: help.html

wcag issue 32

pull request 118

3.2.8.5.1 How it Helps

Clearly stating benefits and consequences of each action and selection option helps individuals avoid mistakes. This is particularly important when the results cannot be easily corrected, lead to safety risks, or may never be known.

For example, a user of a travel site is booking a trip to Geneva. They see an option at a good time, but this ticket is to a different city. They assume the options give are to the location they asked for. They check the dates and times, but, because they cannot read quickly, do not double check the destination. They are taken to a different location, and as a vulnerable user end up at night without accommodation.

In another example, a user sees a laptop for sale at a good price. They do not see the refurbished word in the long description. The laptop is not actually a good price.

3.2.8.5.2 Getting Started

1. Whenever you ask the user to make a selection or take an action, consider whether there are any implied or hidden results that the user should be aware of.
2. If so, clearly indicate those results within the UI and confirm the user is aware of them.

3.2.8.5.3 Examples

Success example:

• When choosing an airline ticket, a customer has to select several price points. Next to each, there is a clear description of what is included. The least expensive option does not include a meal or baggage beyond a small carryon. Once purchased the ticket is nonrefundable. The most expensive option can be refunded or exchanged and includes a meal, carry-on bag, and 1 piece of checked luggage. If the ticket is to a different destination or other unusual or change that could be a risk to the user is asked to confirm the change.

Failure example:

• Each meal option available for selection from an online menu has a fun name. The meal contents, side items, and ability to customize each option is not visible until two steps later in the process. A customer must go several screens down on each item in order to make a decision.

3.2.8.5.4 Technical Details

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

None.

3.2.8.6.1 How it Helps

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

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

3.2.8.6.2 More Details

Examples include

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

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

3.2.8.6.3 Examples

Success examples:

• A phone number, ideally with a feature to automatically call via an interoperable Voice over IP specification.
• An email link using the ‘mailto’ protocol with prefilled “to” and “subject” fields. Note will not work on all platforms or depending of the users mail client.

3.2.8.6.4 Technical Details

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

On coga github: extra-help-aaa.html

wcag issue 52

3.2.8.7.1 How it Helps

People with cognitive and learning difficulties often have challenges managing events and time. In fact, being unable to correctly manage events and time without support is a diagnostic criterion for some groups of disabilities. This results in missing meetings, not submitting a request by a certain date or a form within a specified time period.

Using calendar APIs (or task manager) that allow the user to automatically add events and deadlines to their own calendar can help in many cases, for example:

• When the user copies information into a calendar they often copy the day or time incorrectly.
• The user is challenged processing and retaining time based information.
• The user is challenged in sequencing time bound events.
• The user's skills decrease when tired to such an extent that they have to stop a task. They may wish to reschedule the task.

For example, a user with a learning disability set a doctor's appointment online. Often they copy the detailing incorrectly onto their calendar. However, the website gives them an option to add the appointment to the calendar and sets a reminder an hour before. The user now comes to the correct place at the correct time.

The benefit to users with cognitive accessibility needs is that they can independently manage appointments, deadlines and schedules. The ability to set reminders can reduce the cognitive load associated when processing time bound tasks. Time dependent activities may be monitored and tracked by the user to ensure that they are completed in a timely manner.

Always give the option to set a reminder at the end of the task so that the user does not get interrupted.

It is essential not to add unwanted reminders as this makes the user's calendar too full. This can even prevent them from being able to use their calendar at all. The user is the best person to know how many reminders, and which type, will best meet their needs.

3.2.8.7.2 More Details

Where a standard mechanism exists for the platform or technologies, it must be used. See:

• https://developer.mozilla.org/en/docs/Web/API/notification
• https://www.html5rocks.com/en/tutorials/notifications/quick/
• https://developers.google.com/google-apps/calendar/concepts/reminders
• https://docs.api.ai/docs/reminders-and-notifications

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

Variables that could be considered on 'when to supply a reminder' include:

• Time - at a logical time
• Location - prompted when at an appropriate location
• Context - on computer vs. mobile, on specific site, etc.

This design pattern addresses two broad classes of issues associated with this type of information:

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

3.2.8.7.3 Examples

Success examples:

• A health care site allows you to set a local medical appointment. Once the appointment is set the user is given the option to add it to their calendar (automatically) with a reminder three hours before. They are also given the option to add or edit the reminder.

3.2.8.7.4 Technical Details

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

On coga github: reminders.html

wcag issue 34

3.2.8.8.1 How it Helps

Providing an easy way for users to give feedback will help people be able to share problems, ask for help, make suggestions and positive comments. If users cannot give feedback easily, problems will continue to exist without the site owner being aware of the problems. It is important to allow users to provide feedback from any point in the process so that people do not get lost when trying to explain why they are stuck. Ideas for improvements and positive feedback will also be missed.

3.2.8.8.2 More Details

Make sure the feedback option is:

• Simple to use;
• Available in all stages of the process;
• Has a process in place to respond helpfully to any feedback submitted;
• Does not make the user provide unnecessary information;
• Does not rely on complex menu systems.

Providing multiple methods for gathering feedback is recommended. For example, on a website, consider providing all 4 options for feedback including live chat, a phone number, a web form and a feedback email address.

Note that chat bots may not be appropriate for this particular type of feedback other than to start the feedback process. These can be extremely frustrating if you cannot easily get to the area you are trying to reach.

3.2.8.8.3 Examples

Success examples:

• A banking website had a major accessibility problem. This problem blocked some customers from paying their bills online. One of these customers found a feedback form on the page where they got stuck. The customer was able to report the problem. A help desk employee reached out to the customer and helped them complete their bill payment successfully. That help desk employee also reported the accessibility problem to the software team. The software team corrected the problem in the next software release. The new design was easier for all users and resulted in more customers successfully paying their bills on time.
• Web Chat or Web Call - An option to provide feedback using live chat or a video call. Note: The live chat or video call feature must be fully accessible. Web chat should not be a distraction and easy to close. Check usability with user testing.
• Phone - A feedback phone number, ideally with a feature to automatically call via Voice over IP. Make sure there are no complex voice menus.
• Web Form - A simple site contact form with no more than 3 required fields
• Email - An email link using the "mailto" protocol with prefilled “to” and “subject” fields. Note will not work on all platforms or all mail clients.
• Interactive Voice Response (IVR) - Provide an automatic option at the end of an IVR to give feedback by pressing a specific digit on the phone.

3.2.8.8.4 Technical Details

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

• SC Shortname: Finding Help - On coga github: clear-text-and-voice.html
• WCAG issue 43

3.2.9.2.1 How it Helps

People with cognitive disabilities are often using add-ons or extensions as assistive technology. This includes:

• Reading of the long form of acronyms;
• Support for text-to-speech with synchronized highlighting of the phrase being read;
• Content simplification;
• Creating mind maps out of the heading structure;
• Support for retaining content that has already been entered;
• Password management;
• Spell checking;
• Changing the symbols or the interface.
• Changing numbers from digits to words and words to digits
• Adding white space between lines, sentences, phrases, and chunks
• Alternative ways to input the content such as speech recognition
• Adding pictures

If these functions are not supported, the author should provide all support all the functions of the add-ons in use as assistive technology.

For example, a user with traumatic brain injury has executive function and memory impairments impacting their ability to remember details such as:

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

Supporting the use of an add-on that simplifies content and adds help (such as the long form of acronyms, and a popup dictionary) enables them to understand most content.

Supporting password management tools enables him to successfully login and avoid being locked out of secure sites.

Storing non-sensitive information and auto complete helps them fill out a form. This suggests common information, like a person's phone number or address. It also helps them avoid making mistakes. It eliminates the need for accurately recalling this information from memory or having to copy and paste it, which is a task that often prevent them from successfully using a form.

When overwhelmed by textual content, they have an extension that inserts symbols that they are familiar with that helps them find the content they need.

However, sometimes a web site stops their extensions and API’s from working. The result is that the use cannot use this web site.

Another example is a person that has a language related disability (e.g. Dyslexia) which may cause them to read at a slower rate. They often miss objects and information that they did not know they needed to read. While high-literacy readers scan text, low-literacy users may read the text “word-for-word.” This means they only know what is written when they have intentionally read out. This is similar to having a narrow field of view and they can be unaware of other items not directly in the flow of text that they are reading. They may also miss things on the page that help them understand what to do. For example, there may be a side bar or call out box which helps make decisions about which link to go to that matches their particular needs. These readers may select the earlier option they encounter, because they may not have noticed (or prioritized) reading that side bar content. They also might miss information that is essential for successfully completing an interaction.

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

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

It is important in any proposed solution to make operational tasks, such as interacting with the IoT, as transparent as possible so that users can focus their attention on the functional aspects, such as relating to content.

3.2.9.2.2 More Details

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

People with cognitive disabilities are often using add-ons as assistive technology. It is essential that add-ons and similar tools work. Otherwise, we need to make the author support all the functions of the add-ons in use as assistive technology.

Exceptions:

• When there is a security or safety requirement, these API's may be disabled for the relevant field
• If it breaks the main function of the site, such as evaluation and testing applications

3.2.9.2.3 Getting Started

Content can be used with APIs and extensions that support those with cognitive disabilities.

Testing verified through the use of some of the APIs appropriate for the content. For example:

• Testing with spell checker and password storage apps or extensions.
• Test with an extension that add to the left click.
• Test with a toolbar that enables simplification or personalization and is designed for people with cognitive disabilities.

3.2.9.2.4 Examples

Success example:

• Browser extension and personalization tool bars work. User is able to apply their settings from a personalization toolbar to improve the usability for them of the page.

Failure examples:

• Password storage applications do not work;
• Distraction removing extension does not work;
• Spell checker extension does not add options to the right click menu, or does not underline mistakes made by the user;
• The correct symbols cannot be added by a simplification toolbar.

3.2.9.2.5 Technical Details

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

On coga github: standardized-apis

wcag issue 46

3.2.9.3.1 How it Helps

A user who has difficulty reading or using Web content can be easily overwhelmed with too much information on a web page. They need to simplify the page to just the critical information that they need and not spend all their energy reading and understanding other content and features. This is also true for users who are easily distracted.

For example, an email program has lots of features and formatting options when drafting an email. This makes it too complex for a lot of people. With personalization the user can have a simple option with only send and cancel options. There is a “to” and subject line but no cc or bcc options. In this setting there is a clear heading (write an email) and they have icons that the user understands.

3.2.9.3.2 More Details

Note that:

• Typically, a simple application has 3 to 6 functions;
• Make sure it is easy to get back to the full featured version;
• You can meet this design pattern by;
• Use aui-simplification on regions and controls;
• Use other attributes in personalization semantics;
• Add a simplification toolbar;
• Provide an alternative version.

3.2.9.3.3 Getting Started

Add aui-simplification=”critical” on content that is in any critical user testing paths.

3.2.9.3.4 Examples

Success example:

• Simplified “reading” view is available and easy to close.

Failure example:

• A busy email program with lots of regions with different controls bars and features such as tagging, group tagging, start a new thread etc. There is no easy way to simplify the page.

3.2.9.3.5 Technical Details

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

On coga github: support-personalization.html

wcag issue 6

3.2.9.4.1 How it Helps

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

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

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

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

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

Other support includes autocomplete and extension that help the user fill out forms and understand the content. Many users with memory or executive functions impairments could not fill in forms without asking someone to help copy over information or check their work. Autocomplete, many more users to manage forms by themselves.

3.2.9.4.2 Getting Started

• Use Html 5 autocomplete on all common fields;
• Add a toolbar that adds personalized images or;
• Add the semantics that can work with a toolbar for personalized images.

3.2.9.4.3 Examples

Success examples:

• Install a personalization toolbar;
• Examples of working pages can be found Implementations of Semantics, also see Getting Started with personalization semantics.

3.2.9.4.4 Technical Details

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

On coga github: support-personalization.html

wcag issue 6