Several screens showing websites and apps. Bubbles float around them with icons like calendar, chat, and shopping cart.

Introduction

This post is based on a panel presentation that I gave at the 2015 M-Enabling Summit in Washington DC on June 2nd. The goal of my presentation was to raise awareness of issues regarding mobile app design and users with cognitive disabilities. Several people at the presentation commented that the issues described would benefit all users — that is true and a good reason to implement design patterns that support access by the widest range of people. One distinction that must be made though is that while these may be usability issues for all users, when an issue creates a barrier or overwhelmingly inequivalent experience for users with a disability it becomes an accessibility issue — an access barrier to the user.

Background

There is currently a group of people working on these issues at the Web Accessibility Initiative within the W3C. A Cognitive and Learning Disabilities Accessibility Task Force (Cognitive A11Y TF) has been created that is part of the Protocols and Formats Working Group and Web Content Accessibility Guidelines Working Group. I am not on the Cognitive Accessibility Task force but I am on the Mobile Accessibility Task Force that is more generally looking at issues related to mobile accessibility. This post represents my own brief thoughts on the topic and may not reflect those of any task force.  The Cognitive Accessibility Task Force is performing the following:

  • Researching gaps in current guidelines and best practices
  • Aggregating research
  • Proposing new techniques (that do not change WCAG)
  • Examining options including possible extension models to WCAG to support cognitive accessibility

Benefits and Challenges of Mobile Apps for Users with Cognitive Disabilities

The simplicity and context focused features of mobile apps have generally provided some benefit to users with cognitive disabilities. Apps tend to have:

  • Less features and thus less distractions
  • Features that tend to be context specific (e.g. Store locator, food menu, etc.)

Thus the mobile first design in some sense has helped to reduce cognitive load of users and direct them to the most needed information without complex navigation requirements. At the same time the design may trigger other issues such as moving content out of sight and out of mind.

Challenges of Mobile Apps for Users with Cognitive Disabilities include, but are not limited to:

  • A smaller screen can mean there is no room for descriptive labels or available options that are hidden
  • Mobile Apps often include advertisements that can easily be confused with main content or layered on top of content
  • Content, especially in a flat design paradigm, may not appear interactive
  • The speed of mobile connections may mean feedback from a user action is not initially obvious

Mobile Best Practices for Users with Cognitive Disabilities

Best practices can be grouped into (but not limited to) the following categories: adaptable, discoverable, distinguishable, and understandable (these categories are my own naming and don’t exactly map to the four WCAG principles) — instead they may represent guidelines within the four principles.

Adaptable

Keep the following in mind:

  • One size does not fit all – One size fits one
  • What works for one person may not work for another
  • Experience should be flexible, adaptable but predictable and consistent

In the example below the wtop.com news site is shown in the Safari browser on iOS. When sites are structured in certain ways the “reader” function of Safari can display the main content without distractions in a linear format at the text size desired by the user.

wtop.com website on mobile device showing menus, headings, and Alerts heading.

The image on the left shows the website without reader mode enabled while the image on the right shows the same page in the “reader” mode.  The reader mode removes colors, enlarges the font based on user settings and hides non-main content.   The reader mode is presented to the user when the site is structured in a way that allows for the adaptation to be enabled.

Discoverable

The user should be able to discover hidden content by visual clues

Not so good apps – Require the user to swipe in from side to display menu or more options but do not provide any indication that a menu or drawer exists.

Better apps  – Provide a hamburger menu to disclose more options.  The hamburger menu lets you know there are options available and where to find them.

Screenshot of a mobile app with a hamburger style menu at the top left that is represented by three horizontal lines.   Screenshot of an app with a slide out menu from the left that was just opened by tapping the hamburger menu.

In the picture on the left a hamburger menu is displayed at the top left of the screen to indicate that a menu is available.  The picture on the right shows the hamburger menu opened   Although no button is shown to collapse the menu.  Having a clear way to close the menu can also assist users.

Overlay Tutorial

Apps often have many and sometimes complex gestures.  Some apps now present a gesture tutorial the first time the app is opened allowing the user to learn and practice the gestures.  The tutorial should also be available to review after it has been closed.

Not so good apps – Gestures are unknown and there is no tutorial to learn the gestures.

Better Apps – Provides a tutorial (coaching) that can be reactivated to walk user through the gestures

The screenshot above shows a gesture tutorial and provides a way for the user to dismiss the tutorial.

The Nielsen Norman Group has some good information on Instructional Overlays and Coach Marks for Mobile Apps.

Things that do and do not look interactive

Not so Good App – Uses images and text that don’t look interactive e.g. don’t look like buttons or touch areas

Screenshot of the Apple notes app showing the done button with no border or background.

In the screenshot above the Done button does not contain a border or background — in this case the text itself implies it is interactive — but other visual clues are beneficial.  In the case of iOS 7+ an accessibility feature exists called “button shapes” that for native apps will display a background assisting users in recognizing interactive elements.  Mobile web apps do not have the benefit of this setting.

Good apps – Have controls with visual clues letting you know they are interactive

    Screenshot of the Apple notes app showing a background behind the done button showing it is interactive.
In this screenshot above the iOS accessibility features button shapes is turned on showing more clearly that the Done button is interactive.  For apps that use non-standard controls or for Android and web apps visual indicators of interactivity should be provided.

Distinguishable Boundaries

When the borders are removed from controls such as input fields it may not be apparent where the input fields are located and what information needs to be entered to submit a form.

Screenshot of a page showing input fields with no borders around them. It is hard to tell where the fields are or if the labels are placeholders for fields.

In the example above there are no field borders on the input fields and the user may not know where to touch to select an input field or know what fields are for input.

Screenshot of form with borders around input fields clearly showing the fields are below the field labels.

In the screenshot above field boundaries are available as borders and it is more clear which fields are for input and which text are labels.

Understandable Labels & Placeholders

All fields that require input must have visual labels.  Placeholders are not labels — they are placeholders and as such should not be used as the sole method of providing visual labels.

Not so good apps – Have fields without labels that will likely be problematic for users who may not know what data to enter in input fields.

Screenshot of a logon screen showing fields with only placeholders. One field has focus and there is no placeholder because the field is focused.

In the screenshot above, placeholders are used to provide field labels.  When the field has contents or in some cases takes focus the placeholder disappears.  This may cause confusion about the purpose of the field especially when the content was not entered in a way that the system will not accept.  Labels that always appear should be added to make this accessible.  Labels do not always have to be text — they can images or icons as well.

The Nielsen Norman Group has a good article on this subject called Placeholders in forms Fields are Harmful.

Understandable Icons

Icons can be very helpful to users with disabilities as they do not require reading of text and the meaning may be picked up quickly.  Keep the following in mind though:

  • Be consistent – e.g. don’t use a hamburger icon for favorites or use a star for favorites and rating.
  • Label icons with text or provide supports when users may not know what they mean
  • Make icons memorable — they should relate to things in the real world that the user can associate with

Icon Challenges include:

  • Symbols are often not interoperable between apps
  • Symbols may be proprietary
  • Learning new symbols may be challenging

Additional Best Practices

  • Prioritize content and options
    • Don’t provide too many options
    • Display important options before the page scroll
    • Resource – http://www.nngroup.com/articles/page-fold-manifesto/
  • Reduce user input requirements (e.g. use a picker rather than text entry)
  • Specify input type (e.g. for number set type to number to display numeric keypad)
  • Provide contrast options
  • Avoid distractors (e.g. SharePoint’s “Focus on Content” option)
  • Provide extra support (audio, tooltips, context help)
  • Use clear language (e.g. avoid unusual words and passive voice)
  • Separate out advertisements (identify as advertisements, provide border, etc.)