Mobile Accessibility: How to Build Apps that Work for All Users

In our mobile-first world, it's imperative that your users can engage with your app through their mobile device. So you need to build apps that will work for all users, on all devices. In this article, leading accessibility experts, engineers, and product designers provide their top tips on building more accessible, inclusive, and usable apps.

On the web, we’ve made a lot of progress, and it’s generally accepted that accessibility is crucial in creating digital products that everyone can use with ease. Mobile accessibility, on the other hand, is still fraught with problems. Even though mobile apps now play a huge role in our everyday life, the majority are inaccessible to some degree. 

In fact, Gian Wild, CEO of consultancy AccessibilityOz, believes that mobile is still in the dark ages in terms of usability and accessibility—a bit like the web in the early 2000s.

“Accessibility features are far superior on mobile devices,” Wild explains. “Still, the sites and apps themselves have many issues. Accessibility errors like traps—a user gets trapped in a component—that we haven’t seen on the desktop web for years are all over mobile sites and native apps. It doesn’t matter how superior the accessibility features on a mobile device are; if they aren’t inherited properly by the site or app—and more often than not, they aren’t—then they might as well not be there at all.”

As app designers and developers, we have the great responsibility to include accessibility best practices by default in all that we do.

Scott Vinkle, Platform Accessibility Specialist, Shopify

Adhering to accessibility standards helps to avoid inadvertently excluding users and leads to happier customers and higher retention rates. This also applies to the experience on mobile.

“As app designers and developers, we have the great responsibility to include accessibility best practices by default in all that we do,” points out Scott Vinkle, Platform Accessibility Specialist at Shopify. 

He says it’s critical for a few reasons:

• Providing inclusive access helps people with disabilities—about 15 percent of the global population—to live independently and with dignity.
• There’s potential for increased income from your app as more people are able to use it successfully.
• Not discriminating against people with disabilities who rely on assistive technology helps to build a positive public perception.
• Baking accessibility into your app will help merchants to avoid digital accessibility based lawsuits.

In this article, leading accessibility experts, engineers, and product designers provide their top tips on building more accessible, inclusive, and usable apps.

You might also like: How to Build a Shopify App: The Complete Guide – Accessibility Principles.

Consider your approach to accessibility 

Accessibility is still often framed as a practice that only a few benefit from, which is why the term is being replaced more and more by “inclusive design.” 

“The word ‘accessibility’ has a lot of baggage,” explains Robin Christopherson, Head of Digital Inclusion at UK tech charity AbilityNet. “It relates to those troublesome checkpoints we need to consider to help disabled users."

Christopherson says the perceived attitude toward accessibility is often a tacit acknowledgement that it's important, but since it's not mandatory, it's someone else's responsibility.

"As long as we consider accessibility as a bolt-on activity, when push comes to shove, something bolted on can equally be dropped off—or forgotten about altogether,” he says.

As long as we consider accessibility as a bolt-on activity, when push comes to shove, something bolted on can equally be dropped off—or forgotten about altogether.

Robin Christopherson, Head of Digital Inclusion at AbilityNet

Christopherson argues that in a mobile-first world, accessibility is a mainstream concern and no longer just for people with a recognized disability. It now relates to everyone every day. 

“We all slide up and down the spectrum of impairment on an hourly basis—or even minute by minute,” he points out. “How many of you have used your phone one-handed today? That’s dexterity impaired. When was the last time you squinted at your phone’s screen when out for a walk? Temporary vision impairment right there. I could go on and on,” Christopherson says. 

“For those moments you need exactly the same considerations as someone with that impairment 24-7,” he adds. “And you’re just as frustrated and inconvenienced when you’ve tapped the wrong item because they’re too close together as someone with a disability is. There’s no difference at all.”

Product designer Luis Abreu, author of an iOS Accessibility Handbook and maintainer of the @mobileappa11y Twitter account, agrees that we all benefit from accessibility. It enables us to use an app effectively and at the same time grows our customer base and satisfaction. 

“Accessibility also provides both convenience and comfort for people with none or less severe impairments, as well as independence for many,” he explains. “I’ve lost count of how many times I’ve enabled subtitles because it’s too noisy around me or I don’t have any headphones and don’t want to disturb someone nearby. [Screen reader] VoiceControl on iOS is also great for when you’re cooking!”

Also, as we’re all heading towards stronger, permanent impairments as we age, designing for ableism is a short-sighted strategy. Keep inclusive design in mind from the start. 

You might also like: Universal Design: 11 Practical Tips to Make Your Sites and Apps More Accessible.

Plan for accessibility 

Thinking about accessibility and inclusion right from the start is in fact the most crucial step to making sure everyone can use your app, believes Rob Whitaker, an iOS software development engineer for Capital One UK and author of Developing Inclusive Mobile Apps as well as the Mobile A11y blog.

“Think about the feature you're about to build,” he advises. “How will people with different abilities and in different circumstances experience this feature? Are you excluding anyone? Are you giving everyone an equivalent experience?”

Whitaker recommends creating user profiles as a great way to consider these questions. For example, a profile of someone who is a new parent and whose attention may be elsewhere and only has one free hand. Or someone with a hearing impairment who will miss out on audio cues or speech. 

“Disability occurs when we fail to consider what effect our systems will have on different people,” Whitaker explains. “Considering accessibility from the start will not only make your feature more accessible, it's more time- and cost-effective, as you won't need to go back and fix so many problems.”

Check your app for common accessibility issues

Inclusive design and accessibility advocate Eric Bailey recommends checking your app for common accessibility issues before testing it with disabled people (and paying them for their time). 

“This frees up the person who’s conducting the tests to focus on more granular concerns that you may not be aware of as a non-daily assistive technology user,” he points out. Bailey suggests following this checklist: 

1. Does the app support the phone or tablet being rotated into landscape mode? If not, you’ll have to update it.
2. Does your app support text resizing? If it does, is the text obscured by other UI elements after being resized?
3. Iconography is really important for people with cognitive disabilities, so check if your icons have labels. Do the icons you’re using make sense? Do you even need them?
4. Does each image have a concise alternative description that accurately describes its content?
5. Is your app intended for a general audience? If so, are you using short, simple sentences? Are there complicated concepts or jargon that can be revised?

Danny Lancaster, test analyst at human-centred research, design and development company Nexer Digital agrees that the option for users to have their apps automatically update the text size to their preferences is an essential feature for a lot of people, though not all apps allow it. 

“While we must always ensure this option is available, we cannot solely rely on it as text can sometimes appear unreadable,” he advises. “We recommend that you perform manual testing and make adjustments with different text sizes.”

Ensure you cover baseline requirements

Shopify accessibility specialist Scott Vinkle, meanwhile, suggests ensuring you follow these best practices at a high level:

• Actions that can be completed with a mouse can also be done with a keyboard alone. 
• Focusable controls feature a visible focus indicator and flow in a logical order.
• Make sure colors have enough contrast to be readable.
• All images must have a text alternative; either a description of the image or an empty value for decorative imagery.
• Headings are present and in a logical order.
• All form field labels are visible and connected to their related inputs.
• Custom components convey accurate role, state, and support expected keyboard interaction.

The axe browser plugin can be used to test specific sections of a page, like the customer reviews portion here.

To help with these items, include tooling in your daily workflow, Vinkle recommends using a code linter, such as webhint, or a browser extension, such as axe. Pairing automated tools with manual keyboard testing and screen reader testing will go a long way in providing an accessible user experience. 

Follow mobile accessibility testing guidelines

The Web Content Accessibility Guidelines (WCAG) also apply to mobile sites and native apps, but when they were developed, mobile wasn’t as ubiquitous as it is now. Thus, as the guidelines don’t cover all aspects of mobile accessibility, merely conforming to WCAG2 (or WCAG 2.1) doesn’t provide for a fully accessible experience for users with disabilities. 

AccessibilityOz founder Gian Wild therefore chaired the mobile site sub-committee of the ICT Accessibility Testing Symposium to develop a Mobile Site and Native App Testing Methodology that’s available under Creative Commons.

These guidelines, an amalgamation of accepted mobile accessibility testing standards from around the world, are meant to be used in conjunction with WCAG to ensure that sites and apps are accessible to people with disabilities using mobile and tablet devices.

“The guide was written with the intent to clarify the unique needs of users with disabilities who use mobile websites and native apps and to raise the bar for the web development community,” Wild explains. “As a committee, we felt that there needed to be some kind of guidelines that were updated regularly, as regularly as the technology, and we felt that WCAG wasn’t moving fast enough.”

"In fact, if you do one thing to make your mobile site or native app accessible, it should be this: use real devices and not simulators."

Wild stresses that it’s really important to test with real devices. In fact, if you do one thing to make your mobile site or native app accessible, it should be this: use real devices and not simulators.

Examples of what is missed when testing on a simulator and not on a device.

According to the methodology, there are four main testing methods in mobile site testing: 

1. Testing on real mobile and tablet devices
2. Testing on those devices with assistive technologies
3. Testing on responsively sized windows on desktop
4. Testing on desktop 

Native apps should be tested on devices and with assistive technology. 

The steps for testing mobile sites then are:

1. Identify devices
2. Identity site type and variations
3. Test critical issues
4. Test mobile specific-issues
5. Test mobile assistive technology and feature support

The steps for native app testing are the same with the exception of step 2, which for native app testing is “Define application functionality.” 

Authoring tool accessibility

If your app enables authoring of web content, such as product reviews, you are also required to meet Authoring Tool Accessibility Guidelines (ATAG), Scott Vinkle advises.

According to the ATAG specification, designing your app to meet WCAG and incorporate inclusive design is a great start. The other part is ensuring the app helps content authors to produce accessible content. 

Test your app with the assistive tech of mobile devices

Modern mobile devices come with a myriad of built-in accessibility features (see the iOS and Android overviews) to support a wide range of abilities. 

“If you made a spider-diagram of every option in the iOS Settings app, you’d see that well over half the items are found under Accessibility,” Christopherson points out. “Ignore this fabulous trove of features if you wish, but only if you’ve never dictated a message, grabbed text from a print document with the snap of the camera, done an image search or even tried out dark mode. All of these started out as accessibility features.”

To be sure your app behaves as expected and to get a better insight into how people might experience your app, test it by enabling tools such as VoiceOver and Voice Control on iOS and TalkBack and Voice Access on Android, as well as digging through the accessibility settings on your supported devices. 

“Try navigating your feature,” Whitaker recommends. “Can you access everything you expect, and is it all in the right order? Does the app look and function as you intended? Are any parts of the interface a real effort to navigate?”

Devon Persing, Technical Program Manager for Accessibility at Shopify, agrees but cautions that development teams often focus on screen readers only, which can lead to assumptions. 

“Working with people who have disabilities as colleagues and as usability testers gives a broader picture,” she explains. “For example, it may not occur to designers and developers that people may use several types of assistive tech at once. A user with a migraine or a brain injury may turn off animations and also adjust colors to decrease eye strain. A user with vision issues might bump up the font size of apps and also use magnification. Individuals' preferences are as varied as their experiences with disability.”

Individuals' accessibility preferences are as varied as their experiences with disability.

Devon Persing, Technical Program Manager for Accessibility, UX Operations, at Shopify

Developers should familiarize themselves with all the accessibility features on the devices you support, Persing recommends. Make sure users can use your app without motion enabled, or without your chosen colors visible. Make sure controls are labeled clearly, and views are built to make the visual order of your content. If you’re unsure how to do this, refer to the step-by-step instructions that are provided in the Mobile Site and Native App Testing Methodology. 

The iPhone and iPad accessibility support page presents a wide picture of the types of built-in accessibility tools that are available.

You might also like: 10 Ways to Create Delightful and User-Friendly Web Animation.

Use accessibility auditing tools to test early and often

A great way to catch potential accessibility issues early and often is to incorporate auditing tools into your development workflow, advises full-stack engineer Erin Doyle, who runs an online course on developing accessible web apps with React. 

In particular, she suggests the following tools, which can all be automated in your Continuous Integration solution:

• The ESLint plugin eslint-plugin-jsx-a11y to analyze and catch issues in static code
• Accessibility testing library @axe-core/react to audit the elements that are available in the DOM at runtime
• jest-axe to add to unit tests
• cypress-axe and @axe-core/webdriverjs for end-to-end tests
• A plugin for Storybook to test your UI components for accessibility issues
• Lighthouse to test entire pages

“While auditing tools are a big help in catching common potential accessibility issues early, they are no replacement for performing manual testing,” Doyle warns. They can only catch around 20 to 30 percent of potential issues."

Doyle recommends using auditing tools to find the "low hanging fruit," so that there are less issues to uncover in manual testing with various different screen readers across different desktop and mobile browsers.

Manual testing should also include testing with a keyboard only for desktop applications and using high contrast tools or modes built into the operating system to make sure the app doesn't have any color contrast issues.

Consider mobile accessibility when working with React

When developing apps with React, Mark Steadman, accessibility developer services consultant at Deque, suggests looking out for the following issues to ensure the content is accessible on mobile:

• Ensure all your pages have titles. This has to be done by the developer as it’s not done by default in React. 
• Focus control is not standard in React when routing between pages, so you must control where the focus goes after going between pages.
• Any dynamic content, such as status messages, must have a proper announcement.
• Make life easy for yourself, and use semantic HTML as much as possible (<button>, <a>, <input>) to get the full accessible benefits. 
• Use fragments wherever possible so that extra <div>s do not get added to your page that could break proper HTML markup.

“Also be aware of dynamic ARIA [Accessible Rich Internet Applications] attributes,” Steadman’s colleague, accessibility developer services consultant Taylor Richards adds. “They can sometimes confuse screen readers and end up not being read to the user properly.”

This isn’t normally the case when switching between true or false, but for certain ARIA attributes where an ID is required, such as describedby or labelledby. Make sure those IDs are in the DOM before the screen reader loads it, Richards says.

Make use of the React Native Accessibility API

If you use React Native to build native apps, Léonie Watson, director of accessibility consultancy TetraLogical, recommends checking out the accessibility API that works with the platform accessibility API on Android and iOS. That way you can create apps that are usable by people who use accessibility services like screen readers on those devices.

There are several properties that are available to the accessibility services on both Android and iOS devices. These include:

• The accessible property is a boolean attribute that indicates an element is accessible. When accessible={true} is set, the element and its children are treated like a single accessible and focusable element.

• The accessibilityLabel attribute is a string that gives the element its accessible name. When accessibility={true} is set, it’s good practice to give it an accessibilityLabel because it gets announced by screen readers.

• The accessibilityHint attribute sets an optional string that’s used as the element’s accessible description. It supplements the accessibilityLabel by providing an additional hint about what the element does.

• The accessibilityRole attribute sets the element’s role. The role of an element tells accessibility services what the element is. There are 27 different roles in the API; for example, accessibilityRole={checkbox}, accessibilityRole={button}, and accessibilityRole={alert}.

• The accessibilityState object has several boolean properties that describe the state of the element. For example, checked, disabled, expanded or selected.

• The onAccessibilityTap attribute assigns a custom function to be triggered when someone using an accessibility service double taps the element.

Understand inconsistencies in the React Native Accessibility API

Watson points out that, in addition to the properties that are available to accessibility services on both Android and iOS devices, the React Native Accessibility API also has properties that are unique to each platform.

These properties include the following:

Android

• The accessibilityLiveRegion attribute indicates the content of the element is a notification for screen reader users. Like live regions on the web, accessibilityLiveRegion can be set to none, polite, or assertive.

• The importantForAccessibility attribute controls if a view fires accessibility events, and if it's reported to accessibility services. It’s used to avoid conflicts between sibling elements that overlap in the UI, and can be set to yes, no, or no-hide-descendants.

iOS

• The accessibilityIgnoresInvertColors attribute indicates that user preferences for color inversion should be ignored. It should only be used when inverting colors would make content unusable–viewing a photograph, for example.

• The accessibilityViewIsModal boolean attribute indicates that the children of any sibling elements should be ignored.

• The accessibilityElementsHidden boolean attribute indicates if the accessible child elements of the element should be hidden from accessibility services. For example, accessiblityElementsHidden={true} on view A hides all the accessible children of view A.

• The onAccessibilityEscape attribute adds support for the native iOS escape gesture (a Z shape drawn on screen) to custom functions.

• The onMagicTap attribute adds support for the iOS magic tap gesture to custom functions. The magic tap gesture is a two finger double tap that triggers the most relevant action for a view–answer an incoming call or end a current call, for example.

Develop your app for a mobile-first world

The slow progress in mobile accessibility is often simply due to the fact that many developers and product teams don’t realize how much “mobile-first” applies to people with disabilities. 

“Almost everything can be done on our mobiles now, and as mobile devices tend to have great accessibility support and features, we find that people with disabilities are using them even more than the general population,” Wild says. “So you really can’t get away with just making your desktop site accessible. That’s not going to help the person accessing your site or app through their phone!”

There are many ways to ensure content is accessible on mobile devices. Keep the tips outlined above in mind when developing apps and help raise awareness of the issues with team members and stakeholders. Together, we can build a more accessible mobile web that benefits us all.