As mobile developers, building accessible apps is a fundamental part of our jobs. And yet, the simple fact that making our apps work means making them work for everyone is often overlooked as companies optimize for rapid growth and revenue.
This isn’t a technology problem—there are numerous tools available to help us center accessibility in our work, and Apple and Google provide a variety of assistive technologies, as well as tooling and APIs that make it easy to integrate them with our own products. Rather, it’s a shortcoming of the product development process, and one that we can change.
To create truly accessible experiences that everyone can enjoy, we need to reframe how we approach mobile development, starting by embracing an accessibility mindset.
The accessibility mindset
First and foremost, adopting an accessibility mindset requires understanding that users are diverse, that accessibility relies on customizability, and—this bears repeating—that providing accessible experiences is part of our jobs as mobile developers.
Users are diverse
Apple classifies its accessibility features into four categories—cognitive, motor, vision, and hearing—and each presents a unique set of considerations and challenges for developers. People who are hard of hearing may require sensory alerts or mono audio, while those with limited motor function may rely on voice controls and custom keyboards. And while we often think about disabilities in terms of extremes, it’s more accurate to conceive of them as spectrums. Visual impairments, for instance, come in many forms and degrees, from color blindness to partial or complete loss of vision.
Disabilities aren’t always permanent, either. They can be temporary or situational. A person with temporary vision loss due to recent laser eye surgery, for example, may benefit from accessibility features designed for those with permanent visual impairments. This illustrates how improving the accessibility of our apps can have valuable and wide-ranging positive impacts for all of our users.
Accessibility relies on customizability
An accessible mobile app should enable customization, abstracting the user experience to a level that allows for multiple input and output mechanisms. Not everyone consumes visual information, for example; some might use your app by listening to a screen reader or engaging with a Braille display. Likewise, not everyone will touch or swipe a screen; instead, they may use voice controls, a keyboard, or a switch.
Customization is at the core of accessibility. Consider Dark Mode, Siri, and subtitles, three accessibility features that double as ways to customize the user experience. The dual nature of these features—enabling access for those with disabilities, offering better UX for anyone interested—can be summed up by the title of a WWDC 2017 talk by Todd Stabelfeldt, an entrepreneur and computing technology expert who is quadriplegic: “Convenience for you is independence for me.”
Twitter is a prime example of an app that enables a high degree of customization. The company offers dark themes (especially helpful for light-sensitive users) alongside other display and sound options, including ones not available in an OS’s settings, such as disabling autoplay and changing how screen readers communicate tweets aloud.
Providing accessible experiences is part of our jobs
Just as we wouldn’t knowingly write code with bugs, we shouldn’t knowingly write inaccessible features. In a video shared on Twitter, Apple engineer Novall Swift said, “We have one job, and that’s to make our apps work. If you’re not implementing accessibility features, you’re forgetting about making it work for a lot of people.”
This is the essence of the accessibility mindset. If you discover an accessibility issue in your app, treat it as a bug, not a feature for the backlog. You may not have a perfectly accessible app from day one, but the goal is to start from a strong, inclusive foundation, and to make constant, incremental improvements.
Championing accessible development
In most cases, you’ll need the support and commitment of your entire organization in order to build more accessible apps. We’ve all worked for companies where leadership finds a bug and, no matter how much of an edge case it is, fixing it suddenly becomes a team’s focus. So why, when it comes to the inaccessibility of a product, do we have to make a business case for remedying it? It’s often a question of priorities, and we all have to be prepared to push for accessibility to rank high.
Prioritizing accessibility as an organization means keeping it top of mind throughout the product development process, and triaging accessibility issues as you would any other bug—by considering how it will impact your users. Not being able to interact with an app using a screen reader will have an outsize user impact, while a glitch in an animation, however unattractive, will be much lower stakes.
Often, raising awareness of accessibility concerns can be enough to prompt a company to start addressing them. But if leadership needs more convincing, you might remind them that roughly 15 percent of the world’s population lives with some form of disability, according to the World Health Organization. That’s over a billion people you’re potentially excluding from your app. You could even point to the potential revenue impact—consider, for example, that the spending power of disabled people is nearly $500 billion in the U.S. alone, according to a 2019 report by the development firm Accessly.
Furthermore, you can get sued for developing inaccessible apps. The U.S.’s Americans with Disabilities Act, the UK’s Equality Act, and the European Union’s European Accessibility Act all require products and services to be accessible. Here’s a notable example: In 2019, the U.S. Supreme Court upheld a lower court decision against Domino’s after a man sued for being unable to order pizza on the chain’s website or mobile app using screen-reading software.
Put simply, making accessibility a priority is a win-win for businesses. It allows you to offer a more inclusive experience for current and potential users, improve your bottom line—and keep your company out of court.
An accessibility tool kit
You’ve committed to prioritizing accessibility as an organization. Now, where to start? Building a more accessible app doesn’t have to be a complex or daunting undertaking—here are a few simple but impactful first steps toward offering a more accessible experience.
Check the color contrast
An insufficient color contrast ratio between text and background can make your app difficult to read, especially for color blind users and those with low contrast sensitivity. Aim for a 4.5:1 contrast ratio; if you can achieve a 7:1 ratio, especially for text smaller than 14 or 18 points bold, even better. There are plenty of free color contrast calculators online to help you out, including WebAIM’s Contrast Checker. If you’re an iOS developer, there’s one built right into Xcode.
Create large touch target areas
The minimum recommended touch target area is 44 by 44 pixels on iOS and 48 by 48 density-independent pixels (dp) on Android. Making buttons as big as possible greatly improves the user experience for people who have tremors or difficulty with fine motor skills.
Convey information in multiple modes
Use a combination of sound, haptics, iconography, text, and colors so all users can perceive and understand your content. The Spotify app is a good example of this combination of outputs in action. Its shuffle and repeat buttons are toggles that are white when they’re off and green when they’re on; the “on” state is also marked by a small dot below the toggle, resulting in a button that’s comprehensible to more people, including those with color blindness.
Leverage native components
Apple and Google have put in the work to make their components accessible, so using them will make your app reasonably accessible from the outset. If you need to create custom components, go for it, but remember you’ll have to expend the effort to make them accessible. For instance, if the component relies on complex gestures, consider how people with motor impairments will be able to use it. If you’re creating a visual component, consider how you’ll translate it for someone who has limited vision or uses a screen reader.
Stick to system-wide accessibility settings
When leveraging native components, your app will adjust automatically when a user enables certain OS-level accessibility settings. For example, if you use predefined styles for your UILabels, text will automatically become bolder when the user enables the Bold Text option. If you’re creating custom components, you can leverage iOS properties to verify whether the user has enabled any accessibility settings and adjust accordingly. For example, you can use the UIAccessibility property isReduceMotionEnabled to check whether they’ve enabled the Reduce Motion option, or isBoldTextEnabled to identify when they’d like to use a bold version of a custom font. (Android offers fewer such properties, but it does allow you to check if the ANIMATOR_DURATION_SCALE setting is equal to zero.)
Audit your app
Xcode’s Accessibility Inspector and Android’s Accessibility Scanner can help you identify potential accessibility issues, including missing accessibility labels (called content descriptions on Android), low color contrast ratios, and too-small touch target areas.
Beyond the basics
There’s so much more we can do to make our mobile apps accessible. We can test them with screen readers on real devices, and improve the experience with iOS and Android’s screen readers, VoiceOver and TalkBack. We can design flexible interfaces that can accommodate large text sizes or work well with Apple’s Dynamic Type. And we can listen to our users when they express their wants and needs. People with limited vision may ask for higher contrast, bolder text, or reduced transparency. People who experience dizziness or seizures from repetitive animations or flashing images may want to reduce or remove animations. We can be good citizen developers by honoring these preferences.
To make our apps a global success, we have to include as many people as possible in the markets we serve. To create delightful experiences, we need to build apps that all users can delight in. Once again, ensuring our apps are accessible is an essential part of our jobs—plus, it’s just the right thing to do. Equipped with this knowledge and an accessibility mindset, we have what we need to push for accessibility to be a priority, as it should be.