Mobile Applications and Litigation: Why Accessibility is Important and What to Consider before Launching, Part 2 of 2

Mobile App Accessibility Pitfalls, Plus an Intro on Testing for Accessibility.

By Sanjay Nasta and Paul J. Adam (About the Authors)

This article discusses mobile accessibility best practices. It is adapted from the August 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.

Ensuring Mobile Apps are Accessible by People with Disabilities: Tips and Testing Guidance for Designers and Developers

In “Mobile Applications and Litigation: Why Accessibility is Important and What to Consider before Launching, Part 1 of 2,” we discussed the human and legal cases for accessibility, what makes accessible mobile application design similar to and different from accessible website design, and what you need to know to implement mobile app accessibility.

In this article, we’ll look at thirteen specific accessibility issues that prevent users with disabilities from using a mobile application, thus exposing organizations to potential legal action or complaint.  We’ll also cover how to audit mobile applications for accessibility.  While somewhat technical, this article will provide a substantive overview of development best practices to implement and snafus to avoid when designing a mobile application.

In many cases, we will refer to the Web Content Accessibility Guidelines (WCAG) 2.0 success criterion that pertains to issue at hand.  As mentioned in Part 1, WCAG 2.0 is the internationally recognized body of recommendations for making digital content, whether websites or apps, more accessible—and generally more usable for the population at large.

13 Common Mobile Accessibility Issues

There are many accessibility issues to think through during the design and implementation phases of a mobile app or mobile website.  Based on our experience, here are the most common application development practices that prevent users with disabilities from navigating or using your app well.

To make sure that your application is accessible, your design and development teams need to steer clear of these practices when coding your mobile website and mobile applications.

1. Disabled Pinch-To-Zoom — Pinch-to-zoom is a very useful accessibility tool.  It allows those with visual impairments to zoom in on a piece of content with a simple multi-touch gesture.  Mobile web pages that use the meta viewport property with user-scalable=no can prevent mobile users from using the standard two-finger pinch-to-zoom gesture that enlarges a website’s text and images.  This very common gesture should never be disabled.

2. Unspoken Form Validation Error Messages — Not having validation error messages accessible to screen readers is a common problem in both mobile websites and native apps.  For a sighted user, when a user submits invalid data into a form, a red error message appears.  For screen reader users, developers need to test that the error message, along with any suggestions to fix, are spoken aloud so a blind user hears what errors they made and can correct them.

3. Unspoken Success and Announcement Messages — Developers often show success and announcement messages at the top of the screen when an action has completed.  Screen readers will not read these aloud without the proper accessibility announcement notification method for that app.  For mobile web views, developers need to use WAI-ARIA Assertive and Polite Live Regions, e.g. <div role=”alert”> for assertive announcements and <div role=”status”> for polite announcements that won’t interrupt the user.  For native apps, there are specific accessibility APIs to enable the screen reader to speak success and announcement messages aloud.  The World Wide Web Consortium (W3C), which develops WCAG and other web standards, has ARIA-based alert examples on its website.

4. Placeholders Used Without a <label> — Example text placed inside a form field (also known as “placeholder text” or “inline labels”) is widespread in mobile apps and sites.  This common practice happens when, rather than using the standard <label> text element, designers use the <input> element with a placeholder attribute.  Since this puts the text within the form field rather than above or beside the field, designers do this to save space or effect a simple, clean look.  Their reasoning is that users see this sample text (e.g., “Emergency Contact Name”) within the field and know what information it requires.However, this practice is bad for cognitive accessibility and bad for usability.The text usually disappears once the user begins entering their information, and doesn’t reappear.  Among other things, this transient form field text puts a strain on short-term memory and prevents people from checking their work before submitting the form.  Another significant issue is that placeholders have very low contrast and do not meet WCAG accessibility requirements. WCAG 2.0 AA is the accessibility standard enforced across the globe so it’s important to meet its color contrast requirements even if you consider placeholder help text to not be necessary for users to complete the form.For accessibility and usability, we recommend designers use the standard <label> element for all fields, ensuring that the text label always appears above the input field.For example, the bad code without a visible label would be: <input type=”text” placeholder=”First Name”> whereas a properly labelled input would be: <label for=”first”>First Name</label> <input id=”first” type=”text” placeholder=”John”>.

5. Lack of Unique and Meaningful Page Titles — Single-Page Applications (SPAs) are web apps that load a single HTML page and dynamically update that page as the user interacts with the app.  A common problem in SPAs is the lack of a unique and meaningful page title for every screen in the app. Single Page Applications dynamically load in the new screens rather than opening a new HTML document, so developers don’t think about dynamically updating the page <title> text each time they load a new screen.  However, the page title is a key indicator to an application user about where they are in the application, as well as what page content they can expect.  Having a unique and meaningful page title is a specific WCAG requirement called Success Criterion 2.4.2 Page Titled.

6. Bad Focus Order — In very basic terms, “focus” indicates where a cursor is or what item, such as a menu item or button, is pending activation.  On mobile phones, the screen reader shows an outline around the currently focused element that would be activated if the user double tapped.  SPAs that load in new screens in a step-by-step sequence need to move the keyboard focus from the last focus area of the previous screen to the next logical area of the new screen.  Otherwise, assistive technology users will have to tab and swipe around to find the new content each time a new screen loads.  Bad focus order affects keyboard and screen reader users because their focus will either remain on the old content or possibly skip over new content.

7. Modal Dialogs Focus Issues — A modal dialog is a window that forces the user to interact with it before they can go back to using the primary application.  A great example of this would be a prompt for saving or the Open File dialog.  The problem with modal dialogs is that they don’t grab the screen reader’s focus after opening the dialog.  In other words, modal dialogs don’t put their focus into the most logical place in the dialog so the user can take action on it.  Furthermore, developers often don’t restrict keyboard and screen reader focus within the main content area, even though that area has been visually grayed out and is disabled.  The result is that even though the screen reader user opens a modal dialog, they are still on the button that opened it.  They swipe around to try and read the new content, but remain underneath the modal dialog in the grayed out main content, unable to take the action needed.

8. Hamburger Menus and Accordions Not Implemented Correctly — Hamburger menus and accordion design elements can cause accessibility issues for the visually impaired if not coded correctly. The “hamburger” menu icon, made up of three horizontal lines stacked on top of each other, appears at the top of many mobile screens, either on the far left or on the far right (Figure 1). By touching, tapping, or clicking on the hamburger menu icon, it opens up a side menu with a selection of options or additional pages.
   

   Figure 1.  Hamburger Menu Example: The top example shows a hamburger menu on the right in its contracted and expanded states.

    

   An accordion is a design element that expands in place to expose some hidden information.  Accordions push the page content down instead of superimposing content on top of the page as with overlays or modal dialogs.  A common example of an accordion element is a menu that reveals submenu items when a user activates a menu heading.  The W3C example in Figure 2 shows an accordion element that reveals form input fields relevant to different categories of information. See the original interactive accordion examples on W3C.github.io to get a better idea of functionality.

   

   Figure 2.  Accordion Element Example: In the three-screen figure above, the left screen shows an accordion element with all options closed.  When a person clicks or taps the “Personal Information” section, it expands to reveal input fields related to personal information, pushing the second section, “Billing Address,” further down the screen, as shown in the center screen. The right screen shows that the Personal Information section closes and different input fields display when the user activates the “Billing Address” section.

    

   Expanding and collapsing hamburger menus and accordions need to have meaningful accessible names and a dynamic state that changes (e.g., <button aria-expanded=”true”>, <button aria-expanded=”false”>) to make them usable for screen reader users.  When coding accordions and menus, developers need to offer keyboard-only users the ability to tab to the accordion or hamburger menu and make sure they can see their visible keyboard focus outline.

9. Fake <div> Buttons — Web developers often simulate buttons by using <div> or <span> elements because these simulated buttons are easily styled using CSS.  In native apps, the simulated buttons problem shows up when developers code a button out of a non-button element like an <ImageView> or a totally custom control not derived from a native button.  Non-standard buttons cause significant accessibility problems.  While the buttons work fine when you tap or click on them, they are not keyboard or screen reader operable.  Also, simulated buttons do not expose themselves correctly to accessibility APIs.  The simple answer is to use a real <button> and not a <div>.

10. Unsupported Dynamic Type — When creating apps, it is important to support dynamic type.  Dynamic type allows users to specify their preferred font size (Figure 3).  This makes it easy for visually impaired users to increase the size of the text.  Native apps need to tie into the operating system’s Large Text accessibility APIs to check when a user changes their text size preferences.  The API will then be able to update the app’s text to respond to the user’s new text size settings.  Supporting dynamic type is easier when using default native views rather than custom views.
    

    Figure 3: Dynamic Type Options: Dynamic type allows users to specify their preferred font size. The “Larger Text” accessibility settings, shown here for the iPhone but also available for Android, make it easy for visually impaired users to increase the size of text in any application.

11. Poor Contrast between Text and Background — WCAG’s color contrast requires choosing colors that provide enough contrast between content and the background so that anyone with low-vision impairments and color deficiencies can perceive the content.  WCAG 2.0 level AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text.  Large text can have lower contrast because it’s easier to read by virtue of its size.  Many websites and app designs do not meet WCAG contrast ratio requirements.  For example, many apps use light gray text on white backgrounds, red text on white for error messages, and non-standard blue link text that are insufficient for WCAG’s 4.5:1 ratio requirements for normal text.  Input placeholders (see Issue #4, above), form error messages, and gray footer text are common areas for contrast failures.  Designers need to ensure that the text used in mobile web and app designs meet WCAG 2.0 level AA color contrast requirements when measured against the text background.

12. Incorrect WAI-ARIA Usage — Accessible Rich Internet Applications (WAI-ARIA) defines ways to make web content and web applications more accessible to people with disabilities.  It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.Currently, certain functionality used in websites is not available to some users with disabilities, especially people who rely on screen readers and people who cannot use a mouse.  WAI-ARIA, the Accessible Rich Internet Applications specification from the W3C’s Web Accessibility Initiative, addresses these accessibility challenges.  One way it addresses these challenges is by defining new ways for functionality to be provided to assistive technology.  With WAI-ARIA, developers can make advanced web applications accessible and usable to people with disabilities.  Incorrect usage, however, can have unintended effects.Accessibility can be hard enough to understand on its own.  And, developers often write code without testing the results with a screen reader to see if it sounds logical to a blind user.  Add the complexities of a very large WAI-ARIA specification to a lack of developer education and lack of screen reader testing, and disasters often arise.  A common problem is a React modal dialog that places the aria-hidden=true attribute/value on the <body> tag.  This completely hides the entire page from screen reader users.  The browser and screen reader listen to the code, not what’s visible on the screen.  So if your code says to hide the whole page with aria-hidden=true, then they will oblige.To overcome accessibility issues on complex applications, developer education on WAI-ARIA and accessibility is critical.  Testing your code with a screen reader and running it through an automated accessibility testing tool like aXe and the W3C’s HTML5 validator will help avoid a lot of the problems with incorrect WAI-ARIA usage.

13. Missing Mobile Keyboard Usability Enhancements for Input Types — Mobile phones have the capability to display a different touchscreen keyboard depending on the types of data the user is typing on their device.  For example, if you are asking for the user’s telephone number in a mobile form, but you’re popping up the full QWERTY keyboard, then there’s an obvious usability problem.  HTML5 input types let you display a more usable and simplified keyboard for the data types you’re requesting.Mobile designers need to specify the correct keyboard type for the input required.  For example, when including form input fields within your mobile application, make sure that you’re using <input type=tel, number, email, etc.> to make typing on mobile devices easier.  Visit Paul Adam’s “HTML5 Input Types Demo” from your mobile phone for examples of the different virtual keyboards.

By avoiding these common mobile application accessibility issues during development and launch, you’ll provide a much more accessible product that everyone can use.

Testing for Mobile Accessibility

Based on the WebAIM Survey of Preferences of Screen Readers Users, it is clear the iOS and Android platforms dominate the user base.  Therefore, they should be the area of concentration when testing mobile apps for compliance with WCAG 2.0 AA.

To help you test on these platforms, it is helpful to become familiar with the built-in accessibility features of each platform.  Also, both platforms have fully functional screen readers to aid with testing: Google TalkBack on Android and VoiceOver on iOS.  These function in much the same way as desktop screen readers, except that they are largely operated using touch gestures rather than key combinations.  Apple’s VoiceOver software is a screen reader built into its Mac and mobile operating systems.  Both tools read aloud information from mobile screens as the user passes a finger over icons and text.  (Please see “Mobile Screen Readers: iOS VoiceOver vs. Android TalkBack” in Part 1 for more on each system’s screen reader.)

Apple and Android mobile devices also work with Bluetooth-connected braille keyboards.  In addition, “assistive touch” apps available on Apple, Google Android, and other mobile devices help users unable to perform certain gestures, such as a multi-finger swipe, required to use their touch screens.

A Simple Mobile QA Test Process

A complete Mobile Accessibility QA Testing Checklist is available on Paul Adam’s site.  However, a simple accessibility quality assurance test process is:

• Navigate page by semantic elements, i.e., using the VoiceOver Rotor, keyboard navigation, or explore-by-touch to select elements and hear their accessibility properties. See Part 1 for a comparison of the platforms, screen reader navigation (including the VoiceOver Rotor), and keyboard differences between iOS and Android devices.
• Tab, swipe, or arrow key through all elements. Make sure that you can access all elements in a logical way.
• Set focus to each element to verify proper accessible name, role, value, and state is spoken by the screen reader.
• Activate all dynamic controls using the screen reader only.
• Activate all dynamic controls by using just a keyboard alone.
• Check for proper keyboard focus order and focus visibility (this is different from screen reader focus, so disable the screen reader)
• Enter blank and invalid values into forms to test error validation for accessibility. Are errors spoken aloud?

Google Accessibility Scanner

For native Android apps, anyone can conduct accessibility testing right from an Android phone by downloading Google’s Accessibility Scanner app from the Play store.

The app is very simple to use right on your phone and can test any native application for common mobile application accessibility issues.  It will detect issues such as icon buttons missing accessible names, buttons that are too small to tap easily, insufficient color contrast on text, and other frequently occurring accessibility problems (Figure 4).  The Google Accessibility Scanner also provides developer documentation on how to fix the issues found and has the ability to export the list of problems via email.  If you have an Android phone, this is an excellent and free accessibility testing app.

Figure 4. The Accessibility Scanner for Android from Google Play is a highly recommended and free accessibility testing app.

Conclusion

The reason mobile accessibility is important is because mobile phones provide humans with access to the world’s goods and services.  Mobile web and apps provide access to all aspects of human commerce, communication, healthcare, and transportation.  These are vital services that have legal accessibility requirements and should be available for everyone to purchase and use from their mobile devices.  Moreover, if your mobile website or app is not accessible, you can lose business from users with disabilities, as well a very sizable aging population, most of whom will develop disabilities in their senior years.  These users have significant money to spend and are increasingly savvy about using web and mobile apps to meet a variety of needs for themselves, their loved ones, and their businesses.  However, an inaccessible website or application can result in a poor user experience, and discourage or prevent them from doing so.

To create an accessible experience that benefits everyone, be sure to address the 13 common mobile application accessibility issues listed here, and test your application regularly along the software development lifecycle.  Include accessibility in the specification, design, development, and testing phases of application creation.  Also, specify accessibility requirements, such as meeting WCAG 2.0 level AA success criterion, in all contracts for third party platforms used within your application.

The top common mobile accessibility issues are easy to identify and test by developers and quality assurance folks if they have the proper accessibility testing tools, checklists, and training documentation.  Make designers and developers responsible for accessibility testing, and equip them to integrate accessibility within all projects (perhaps start by sharing this document with them!).  And finally, avoid leaving accessibility for the end of a project.  Often, that’s when it’s too late or too costly to make meaningful changes before release.

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. 

(Back to article byline)

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 talk through potential solutions as you pursue making your apps accessible to those with disabilities.

Mobile applications image credit: Fox, Pexels

Related Posts

VPAT: What Technology Vendors Need to Know

WCAG 2.2 Explained - What Designers and Content Creators Need To Know

With Less Than 50 Days Remaining Until Election Day, How Are States Preparing To Make Voting Accessible?