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.
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.
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
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
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.
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.
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.
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.)