Critical Development Considerations for Mobile Application Accessibility
By Sanjay Nasta and Paul J. Adam (About the Authors)
This article adapted from the July 2017 issue of Mealey’s™ Litigation Report: Cyber Tech & E-Commerce. Mealey’s is a subscription-based information provider and a division of LexisNexis. Copyright © 2017 by Sanjay S. Nasta and Paul J. Adam. Any commentary or opinions do not reflect the opinions of Microassist or LexisNexis, Mealey’s.
Why Mobile Application Accessibility?
Does mobile accessibility matter? Mobile has revolutionized how all of us use the internet. For people with disabilities, however, these devices have the potential to usher in unforeseen options for communication, independence, and more—but only if the applications on them have accessibility for the disabled built into their functionality and design. What’s more, as websites come under increased accessibility scrutiny, and a mobile application use rises, many predict that legal actions against organizations with inaccessible mobile apps will also increase.
We’ll cover mobile apps and accessibility in two separate articles. In part one, we’ll look at both the human and legal cases for accessibility. We’ll also dive into what makes accessible mobile application design similar to and different from accessible website design. In Part 2, we’ll look at areas that typically prevent users with disabilities from using a mobile application well, exposing organizations to potential legal action or complaint. Part two will also cover how to test mobile applications for accessibility.
The Human Case for Mobile Accessibility
The number of people with a disability is not small—about 56.7 million Americans have a disability according to the 2010 U.S. Census. According to the World Health Organization, worldwide there are 285 million people with visual impairments, 39 million of whom are blind, as well as more than 360 million people who have disabling hearing loss.[1], [2]
Mobile plays a central role in providing an unprecedented degree of autonomy to individuals with these and other types of disabilities. Mobile devices and applications can provide access to information and services that might otherwise be unavailable without reliance on other people or transportation systems. According to a 2013 study by Georgia Tech’s Wireless Engineering Rehabilitation Research Center, 92% of people with disabilities use a “wireless device such as a cell phone or tablet.” [3] Many of them use a screen reader, a piece of software that relays content and functions audibly to the user.[4]
It is time for organizations to seriously address the accessibility of their mobile content. In the end, building accessibility into an organization’s mobile websites and mobile apps is not about numbers, it’s about people. At Apple’s 2017 Worldwide Developers Conference (WWDC), Todd Stabelfeldt, founder of C4 Consulting, said, “Convenience for you is independence for me.”[5] This successful businessman has been a C4 quadriplegic since an accident severed his spinal cord when he was eight years old.
In an interview, Apple CEO Tim Cook said:
Apple is founded on giving people power to create things, to do things they couldn’t do without those tools. We’ve always viewed accessibility as a human right, and just like human rights are for everyone, we want our products to be accessible to everyone.
It’s a basic core value of Apple. We don’t make products for a particular group of people; we make products for everybody. We feel very strongly that everyone deserves an equal opportunity and equal access. We don’t look at this thing for a return on investment. I’ve been asked that before and the answer is no. We don’t care about that.
Building your mobile website or app so that it is accessible can help unlock potential. Not just human potential, but also the potential to reach and serve a greater number of people, including those who may benefit from accommodation. There are more than 74 million baby boomers in the U.S. alone, many of whom are starting to encounter age-related disabilities. Furthermore, society in general is becoming increasingly used to highly personalized, customizable user experiences, so it makes good business sense to design applications to be usable by the broadest possible audience in a variety of circumstances.
Legal Reasons to Implement Mobile Accessibility
The legal drivers for making mobile apps accessible are the same legal drivers we have discussed in previous commentaries, including “Website Accessibility Litigation: What Business Owners Need to Know.”
Website accessibility litigation has been brought against businesses claiming violations of the Americans with Disabilities Act (ADA) and other federal and state laws regarding vision-related disabilities. In addition to actions brought by advocacy organizations, individual plaintiffs and putative classes have made a number of demands. Many settlements and consent decrees have required the defendant to make their websites and mobile apps accessible. A small sampling follows:
In 2000, Bank of America became the first entity to agree to make changes to its site as part of an accessibility settlement.[6] In a landmark case a few years later, Target paid nearly $10 million, including attorney fees and other costs, to settle a class-action suit brought by the National Federation of the Blind.[7] Charles Schwab and Safeway entered into settlement agreements in 2012 and 2013, respectively.[8], [9] And Sweetgreen, a food service company declared one of the most innovative companies of 2016, also settled a website and mobile app accessibility lawsuit in early 2017.[10]
The drumbeat of accessibility lawsuits hasn’t ended, either: Ride-sharing application developers have been sued because their smartphone apps are not accessible to the visually impaired.[11] And even fast-food giant McDonald’s is not immune to scrutiny—the company recently responded to a lawsuit claiming that the restaurant’s website and mobile app are both incompatible with screen reading software.[12]
We believe that to serve a growing market and to avoid legal issues, it is important to design and develop all digital assets, including mobile apps and websites, with accessibility in mind.
Mobile Accessibility Standards
The standard for making a mobile website accessible is based upon the internationally recognized Web Content Accessibility Guidelines (WCAG), version 2.0, Level AA—the same standard for desktop websites and for mobile apps. These guidelines are written and maintained by the World Wide Web Consortium (W3C), an international community where member organizations, a full-time staff, and the public work together to develop web standards. We discussed details of WCAG 2.0 in a previous commentary, “Section 508 Refresh: How WCAG Impacts Federal Website Accessibility Requirements.”
While people understand that WCAG 2.0 applies to websites, they frequently look for a different standard for mobile apps. However, WCAG 2.0 was designed to be technology neutral and written to evolve with changing technologies. Also, in disability access litigation for both websites and applications, WCAG 2.0 Level AA is the level of accessibility conformance required for companies that have entered settlement agreements with the U.S. Department of Justice. That said, WCAG 2.0 is not simple to apply to mobile apps because there are no code examples or demonstrations for accessible native apps in W3C documentation.
There are two official documents from the W3C Web Accessibility Initiative group that explain how to apply WCAG 2.0 to mobile, as well as to any non-web information communication technology. The latter document addresses video and audio elements, which are frequently part of mobile apps.
- “Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile”
- “Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)”
Designing for Everyone (Inclusive Design)
How does one ensure mobile application accessibility? Accessibility of mobile apps and web pages is best achieved when accessibility is not an add-on feature but part of the design criteria at the beginning of a good design process. After all, good design is not about designing for the organization publishing the app, or for the design team building the app. It’s about designing, with empathy, for an application’s users—all of them.
Approximately one in seven people worldwide have some sort of disability, as do one in five people in the United States. These users are part of your user base. Designers need to extend their user-centered approach to design for users with disabilities. This is best done by developing a deep understanding of users with disabilities—their constraints, capabilities, use cases, and problem solving approaches.
So what are some of the practical steps to designing for everyone?
Include accessibility requirements as part of your overall specification. The BBC Mobile Standards and Guidelines are a good place to start when adopting or drafting requirements. Some important items to consider during the design process are:
- Standard User Interface (UI) Controls: During the design process, use user interface controls that are included in the programming language. Do this as much as possible since standard UI elements have accessibility built into their design. Creating a custom control means you have yet another individual element that requires custom accessibility. Using a standard UI control also lowers the cognitive load placed on users (they don’t have to learn what the custom element is meant to accomplish) and allows development teams to focus on what makes an organization’s app unique.
- Content Resizing: Allow users to resize content. All users benefit from this, but it especially helps users with visual impairments. Designers will need to consider how text and UI elements display as the user resizes.
- Color: Ensure that your design meets WCAG 2.0 Level AA color contrast requirements. Colors are a great way to convey critical information in an app, but with one in twelve men and 1 in 200 women having the most common form of color blindness, they can’t be the only way. Color can be difficult to distinguish in bright sunlight and cannot be perceived by users who are color blind or otherwise visually impaired. Good color contrast also assists people with cognitive impairments. Other cues (shapes, text, alternative text) may also be needed.
- Styling and Readability: A user must be able to complete the core purpose of a page or screen, whether reading or taking action, when background colors, images, layout, type attributes, or features are imperceptible. Assistive technology, such as screen readers, cannot draw meaning from the way an element looks visually (e.g., text that is bigger and bolder than surrounding text); it must have information about why that element is styled differently than the elements around it (e.g., the bigger and bolder text is actually a heading, and designated as such). And some users will change settings (resizing fonts, changing colors for greater contrast, etc.) to suit their needs.
- Touch Target Size: Consider users with motor and vision impairments when designing touch targets. The recommended minimum size for touch targets is 7–10mm in the smallest dimension. Also be sure to design for an inactive space around a touch target. This helps prevent accidentally triggering an action.
Mobile Application Accessibility Implementation
To implement accessible mobile applications correctly, you have to understand some of the basic implementation choices and how they impact accessibility. Implementation is affected by the mobile application type, the platform used, differing screen readers, and various keyboard differences.
Mobile Application Types: Mobile Web, Native Mobile, and Hybrid
Mobile content can be deployed to users using different types of applications: Native apps, mobile websites (or web apps), or hybrid apps.
A native app is a downloadable software application that is platform specific and can be used offline in most circumstances. Native apps need to be downloaded from various marketplaces (Google Play, Apple’s App Store, Amazon’s Appstore, etc.) and installed on a mobile device before running. Newer native Apple iOS apps are coded in Swift, and older apps in Objective-C. Native Android apps use Java for the dynamic portions and XML views for layouts and static content. Xcode is the integrated developer environment from Apple for writing Swift apps for iOS. Google has Android Studio for Android Apps in Java.
If you’re writing a pure native app, you’ll need to learn the Accessibility APIs (application program interfaces) available to the platform you’re coding. For example, iOS uses Swift, not HTML, so there is no “alt” attribute available to explain what an image is about and make it accessible. To give images an accessible name in Swift or Objective-C, you use the .accessibilityLabel property. To make an accessible on Android, you apply an android:contentDescription property value in the XML view (if the image and its meaning is static) or Java code using the .setContentDescription method (if the alt text dynamically changes).
Xcode and Android Studio both give you two methods to apply accessibility properties, either through a graphical user interface (GUI), where you type text values into form inputs and check boxes, or by using Swift or Java code alone without applying the accessibility properties through the GUI. Any accessibility values set in Interface Builder for Xcode or the Properties Panel in Android Studio can be overwritten using dynamic code. For example, when you have a Play button that changes from Play to Pause, you must change that button’s accessible name dynamically in code. Otherwise, the screen reader user would never know the proper state of the button.
A mobile website, or web app, is an internet-based application that has to be launched by a mobile device’s browser. As the source files are stored on a server, Internet connection is required but downloading or installation is not necessary. A mobile website is similar to any other website in that it consists of browser-based HTML pages that are linked together and accessed over the internet. The obvious characteristic that distinguishes a mobile website from a standard website is that it is designed for the smaller handheld display and touch-screen interface.
A hybrid app is a combination of native app and web app. It is built using open web standards such as HTML5, cascading style sheets (CSS), and JavaScript. Like native apps, hybrid apps are downloaded and installed on the mobile devices.
Mobile websites and hybrid apps are made accessible to screen reader and keyboard users by using the HTML4/5 and WAI-ARIA 1.1 Accessibility APIs. So if you know how to make a website accessible using standard HTML coding practices, or already know how to apply ARIA attributes correctly on desktop sites, then you can apply this same knowledge to any mobile website or hybrid app. The VoiceOver and TalkBack screen readers, discussed more thoroughly later in this article, read the accessibility information available whether inside a native app or a web view. For websites and web apps, use standard HTML and JavaScript accessibility methods.
Mobile Platforms: Accessibility on iOS vs. Android
Both iOS and Android devices have accessibility features built in. The accessibility features of iOS are mature; they have been designed into the Apple operating system since it first launched. Android, by contrast, has been trying to catch up incrementally with each new version. By some accounts, they are succeeding. However, the newest versions of Android and the accompanying improved accessibility features are only available on the newest devices.
- There are many more accessible apps in the Apple app store than for Android. The long-term stability of iOS built-in accessibility features means there is a longer history of making accessible iOS apps. It also means that making accessible apps is easier and more robust than on Android.
- All of the default installed iOS apps are accessible. This has not been the case with Android where some of the included apps are not accessible. For example, the included Android web browser Chrome had low levels of accessibility support in years past but now as much better support.
- Android is much more customizable than iOS. One way this has proved beneficial is that it allows people to customize their home screen to better suit their specific abilities.
Something to consider when designing accessible mobile apps or websites is Android device and operating system fragmentation. On Apple iOS, all the devices use the same operating system, whether iPad, iPhone, or iPod Touch. They may use an older version of a device, and to a limited extent an older version of the operating system, but that’s the limit of fragmentation on Apple’s mobile platforms.
Android however, is heavily fragmented with variations of device manufacturers, operating system customizations, UI skins, and upgrade limitations. Android can have different versions of the operating system, the screen reader, and the web browser. Android users can download multiple web browsers, like Chrome and Firefox, with different rendering engines and accessibility support. On iOS, the web browser and screen reader are all tied to the operating system and cannot be independently updated as with Android.
This makes design and testing of accessible apps much harder on Android than it does on iOS. To make accessibility testing easier on both platforms, always use the latest versions of all screen reader, operating system, and web browser combinations. Bugs are fixed and new accessibility support is added with every release, so always do your updates.
Mobile Screen Readers: iOS VoiceOver vs. Android TalkBack
Both Android and iOS have built in screen readers with comparable functionality: VoiceOver for iOS and TalkBack for Android. However, the gestures for each are unique, which means switching between them is challenging.
iOS VoiceOver. VoiceOver iOS is a more powerful screen reader than Android TalkBack. The Apple iOS had many years of accessibility development before Android began implementing accessibility features. VoiceOver on iOS was the first accessible screen reader on a touch device. At the time, most thought it would be impossible for Apple to make a touchscreen phone accessible to the blind. After all, the phone had no physical buttons to feel.
Apple developed a simple solution to make sure blind users didn’t press the wrong button on an iPhone: When a VoiceOver user touches a button, the screen reader first speaks aloud the name of that button. If that’s the button they want to activate, the user then “double taps” to press the button. This allows a blind user to drag their fingers along their iPhone screen and listen to the names of all buttons and text, decide what they want, and then double tap to activate.
iOS also provides the ability to “Read All” from top to bottom without touching the screen. Screen reader users can also swipe to subsequent elements until they go through all available content, which is why a logical reading order is required.
Android TalkBack. TalkBack is very similar to iOS in that users select the button they want first, hear the name of the button spoken, and then double tap to activate that button. VoiceOver and TalkBack allow screen reader users to skip to important parts of the app or website they’re viewing by using the rotor, a dial-like feature that reveals options from which to choose, within VoiceOver in Apple and the Global and Local Context menus in TalkBack on Android. Users can also use keyboard navigation commands, but the rotor and context menus are made to work with touch screen gestures so users don’t have to carry a keyboard around. The VoiceOver rotor and Android Local Context Menu allows quick navigation by semantic HTML elements like headings and landmarks.
Side-by-Side Views of iOS vs. Android Accessibility Controls: These images of iOS and Android smartphone screens show some of the accessibility options available to users. On the left, the iOS screen shows controls for its VoiceOver screen reader, including options to slow down or speed up the rate of reading speed, change the pitch of the reading voice, access the rotor, and more. On the right, the Android screen shows options for navigating pages through settings chosen on the Local Context Menu. From this menu, users may navigate pages by a site’s default settings, or navigate by its links, controls, characters, words, lines, special content, or headings and landmarks, which is the selected option here.
Interestingly, while using a screen reader, many people with low vision prefer to use their mobile device with the screen turned off. The screen-blanking feature is available with a shortcut in iOS. On Android, this can be added with a third-party enhancement called “Shades.”
Keyboard Accessibility Differences
Keyboard operability differs greatly between iOS and Android. On Android, users can tab through all buttons, links, menus, and tabs with a connected Bluetooth keyboard—similar to how they would on a desktop computer. On the other hand, iOS is not keyboard-alone operable. With iOS, users have to turn on VoiceOver or Switch Control accessibility features to use keyboard navigation without needing to touch the screen. Also, the iOS standard keyboard operation behavior is limited to tabbing through form text input fields—and that’s it!
Android has full keyboard operation, so it needs full keyboard accessibility support from developers. That is, all buttons and UI controls must be keyboard focusable: When moving around the application with the tab and arrow keys, selected items should be indicated by an easy-to-see focus outline. Because both TalkBack and VoiceOver show their own focus outlines, keyboard testing should be conducted with the screen reader turned off. Otherwise, testers often confuse the screen reader focus outline for a keyboard outline.
Mobile Apps Are on the Rise—So What Do Businesses Need to Know?
Earlier this year, mobile analytics blog Flurry by Yahoo!, reported that application use increased by 11% from 2015 to 2016, and that the average time spent using apps increased by 69%.[13] It’s not just entertainment and social apps, either. Mobile finance and retail applications are also on the rise. For instance, Bank of America recently reported a 76% increase in use of its mobile app since 2013.[14] As these services and information sources move to a mobile environment, it’s critically important, from both civic responsibility and litigation standpoints, that that content be available to and accessible by individuals with disabilities.
In our next article, we’ll take a look at areas that typically prevent users with disabilities from using a mobile application well, exposing organizations to potential legal action or complaint. In that article, we’ll also cover how to test mobile applications for accessibility. While somewhat technical, it will provide a substantive overview of development best practices to implement and snafus to avoid when designing a mobile application.
Endnotes
[1]. “Visual Impairment and Blindness Fact Sheet N°282,” World Health Organization Media Centre, www.who.int/mediacentre/factsheets/fs282/en/ (Updated August 2014).
[2]. “10 Facts About Deafness,” World Health Organization, www.who.int/features/factfiles/deafness/en/ (Updated April 2017).
[3]. “SUNspot —Use of Wireless Devices by People with Disabilities, Volume 2013, Number 01,” Wireless Rehabilitation Engineering Research Center, www.wirelessrerc.org/sites/default/files/publications/sunspot_2013-01_wireless_devices_and_people_with_disabilities_final1.pdf (January 2013).
[4]. In 2015, Web Accessibility in Mind (WebAIM) conducted a study of more than 2500 screen reader users. Results showed that nearly 70% used screen readers on their mobile devices. Close to half—44% of respondents—indicated that they use mobile screen readers as much or more than desktop/laptop screen readers. Interestingly, Apple dominates in this space: 70% of respondents use iOS, 21% use Android. See, “Screen Reader User Survey #6 Results,” WebAIM, http://webaim.org/projects/screenreadersurvey6/ (August 28, 2015).
[5]. Stabelfeldt, Todd, “Convenience for You is Independence for Me,” WWDC Presentation, https://developer.apple.com/videos/play/wwdc2017/110/
[6]. “Bank of America California and Florida Agreement,” Law Office of Lainey Feingold, www.lflegal.com/2000/03/bank-of-america-initial-agreement/ (March 14, 2000).
[7]. “National Federation of the Blind (NFB), et al. v. Target Corporation: DRA Case Sets First Precedent in the Country Regarding Website Accessibility.” Disability Rights Advocates, http://dralegal.org/case/national-federation-of-the-blind-nfb-et-al-v-target-corporation/.
[8]. “Charles Schwab Web Accessibility Agreement,” Law Office of Lainey Feingold, www.lflegal.com/2012/05/schwab-agreement/ (May 2, 2012).
[9]. “Safeway Web Accessibility Settlement Agreement,” Law Office of Lainey Feingold, http://www.lflegal.com/2013/12/safeway-web/ (December 13, 2013).
[10]. “Innovative Salad Restaurant Agrees to Make Website and Mobile App,” Seyfarth Shaw ADA Title III News & Insights, www.adatitleiii.com/2017/01/innovative-salad-restaurant-agrees-to-make-website-and-mobile-app-accessible/ (January 24, 2017).
[11]. “Ridesharing apps face lawsuits over disability access,” Austin Business Journal,www.bizjournals.com/austin/news/2016/09/21/ridesharing-apps-face-lawsuits-over-disability.html (September 21, 2016).
[12]. “McDonald’s Denies That Website, App Violate Blind Man’s ADA Rights,” Lexis Legal News, Mealey’s, www.lexislegalnews.com/articles/18522/mcdonald-s-denies-that-website-app-violate-blind-man-s-ada-rights (June 28, 2017) and Bilyk, Jonathan, “Lawsuit: McDonald’s website, mobile app not accessible to the blind, violates ADA,” Cook County Record, http://cookcountyrecord.com/stories/511107875-lawsuit-mcdonald-s-website-mobile-app-not-accessible-to-the-blind-violates-ada (Apr. 24, 2017).
[13]. Khalaf, Simon, “On Their Tenth Anniversary, Mobile Apps Start Eating Their Own,” Flurry Analytics Blog, http://flurrymobile.tumblr.com/post/155761509355/on-their-tenth-anniversary-mobile-apps-start (January 12, 2017).
[14]. “22 Million People Use Bank of America’s Mobile App,” The Motley Fool, www.fool.com/investing/2017/05/04/22-million-people-use-bank-of-americas-mobile-app.aspx (May 4, 2017).
About the Authors
Sanjay Nasta is the founder of Microassist, Inc. and the founder of a mobile application development company, which he has since sold. For 28 years, Microassist has partnered with organizations to better educate their employees, constituents, and clients through the use of traditional classroom training, innovative elearning, mission-critical applications, and ever-changing technology, emphasizing online usability and accessibility.
Paul J. Adam is a mobile accessibility specialist and web accessibility consultant focusing on iOS, Android, HTML, CSS, JavaScript, WAI-ARIA, WCAG 2.0, and Section 508. Paul is co-organizer of the Austin Accessibility and Inclusive Design Meetup. He is also a developer of accessibility testing JavaScript bookmarklets, and macOS Safari a11yTools extension.
For More Information on Accessibility
Subscribe to our Accessibility in the News newsletter from the form on this page. You’ll receive a free weekly email with the latest updates on happenings, events, personal stories, legal commentary, and more, from around the globe.
For accessible mobile application development services, contact us to discuss your project needs and concerns. We’d be happy to provide direction as you pursue making your apps compliant with WCAG 2.0 and more accessible to those with disabilities.
Image credit: Rami Al-zayat, Unsplash
Subscribe to Accessibility in the News
Stay informed! Get your weekly update on digital accessibility standards, private and public sector trends, litigation, events, and more.