How to Design for Accessibility with Your iOS App

Ryan Cole on 2022-07-26

As a software engineer at Intuit working on the Mint iOS app, my goal is to create experiences that empower our customers to find the right financial products and put more money in their pockets. One of our core operating values at Intuit is “customer obsession,” which means we fall in love with our customers’ problems, not the solutions, and we sweat every detail of the experience to deliver excellence.

Customer obsession is embedded in the Design for Delight process we follow to develop deep customer empathy through what we call “Follow Me Homes,” where we observe customers using our products in real-life settings to thoroughly understand the problems they face.

It was at one of these Follow Me Homes with a Mint user who is blind when I first realized we weren’t doing enough to deliver a delightful experience for our customers with disabilities. Visually impaired customers had difficulty with aspects of navigating through the app and using more advanced features. So we embarked on a journey to change that and deliver an exceptional experience to our customers who use assistive technologies.

What is accessibility and why does it matter?

According to data from the CDC, approximately 61 million adults in the U.S. live with a disability. That’s roughly one in four adults. Whether their vision, hearing, mobility, or cognitive function is affected, people with disabilities often interact with technology differently than people without disabilities.

Instead of directly touching their phone’s screen, iPhone users with motor disabilities may use features like Voice Control or Switch Control. People with visual disabilities may use larger text or increased contrast between the background and foreground, or they may have the content on the screen read aloud with VoiceOver or communicated tactilely through a Braille keyboard.

In the iPhone settings app, users can customize their experience by enabling various accessibility settings. With VoiceOver, they can tailor it further by selecting the voice used by the screen reader, along with audio speed, etc.

We often use things like color and font size to indicate linked text or section headers. We design beautiful graphs and data visualizations to deliver trends and insights at a glance. But we also need to convey the same information to people who use a screen reader. Luckily, Apple provides a rich set of accessibility APIs for both SwiftUI and UIKit that iOS developers can use to build apps that are fully accessible to everyone.

How we made Mint iOS more accessible

Getting started

Once I realized we weren’t doing enough to deliver an awesome experience for our Mint iOS customers with disabilities, I turned to Intuit’s Accessibility Champion program to learn more about accessibility. I learned how to use VoiceOver on my own iPhone through online tutorials like this video from Apple, and experimented with several different apps with VoiceOver to get a sense of which handled things well and which didn’t.

I was fascinated by talks at Apple’s Worldwide Developer Conference (WWDC) introducing new accessibility features like audio graphs, which provide a way for VoiceOver users to hear a sonified representation of the data in graphs on the screen. I read through tutorials and blog posts from other iOS developers like Ray Wenderlich and Rob Whitaker. I monitored feedback that customers left in the Mint app for terms related to accessibility to find what worked well and what didn’t for our customers. Then I got to work fixing things.

Diving into the code

Luckily, I had time to do this without disrupting my scheduled work. Twice a year, Intuit holds Global Engineering Days (GED), a full week when engineers can work on projects they’re passionate about. For me, that meant a week in November 2021 to dive headfirst into our Mint iOS code and make as many improvements as possible to our app’s accessibility.

I started by doing a full audit of the app with VoiceOver, which revealed more than 200 changes we could make to improve the app’s accessibility. During GED, I led a team of three other Mint iOS developers to fix as many items on the list as possible.

Most of the fixes we made during GED fell into one of these common and easily fixed mistakes:

We also dove into some exciting new accessibility APIs to provide an exceptional experience for VoiceOver users. In iOS 15, Apple introduced audio graphs. While sighted users can see trends at a glance by looking at graphs, VoiceOver users had to swipe through and hear information about individual data points. With audio graphs, the iPhone can play a sonified version of the data, with the pitch of the sounds representing the position on the y axisMost Mint iOS users open the app to a screen with a line chart of their net worth or spending over time. Thanks to our work during GED, these charts now support audio graphs! To add audio graphs to your app, make sure your graph conforms to the AXChartDescriptorRepresentable protocol in SwiftUI or the AXChart protocol in UIKit, and provide simple descriptions of the axes and data shown in your graph. The system will handle the rest.

When an app supports audio graphs, VoiceOver users can access a system-generated screen from which they can hear a sonified version of the data in the graph.

Sharing learnings

Our journey to make the Mint iOS app more accessible coincided with our team starting to adopt SwiftUI. Adding accessibility properties in UIKit is pretty straightforward, but I quickly realized that SwiftUI streamlines accessibility even more. Just like how there are SwiftUI modifiers to set the font or color in a single line, there are also modifiers to easily add an accessibility label to an image, or group labels that logically belong together into a single accessibility element that automatically combines the text from both of them.

I put together a workshop of what I’d learned about accessibility with SwiftUI. The project I used for the workshop, along with examples of components with poor accessibility and how to improve them, is available on GitHub.

I was also intrigued by the possibility of catching accessibility violations at compile time with an open source tool like SwiftLint. Linters for mobile code can be a bit limited in how they apply to accessibility because they analyze code, rather than the UI created by the code. I contributed the first accessibility rule for SwiftLint, which checks for SwiftUI Images that are created without a label and aren’t hidden from assistive technologies like VoiceOver. If you use SwiftLint, make sure you turn on the accessibility_label_for_image rule in your project!

Keeping the feedback loop open!

A key part of being customer obsessed is making sure you’re delivering an exceptional experience to all customers regardless of their abilities. Once you take the time to understand common problems that make apps less accessible, it’s often a simple matter of adding a couple of lines here and there to your code to make sure everything works as expected for people navigating your app with assistive technology. The customer benefit will far exceed the developer effort.

We’re incredibly proud of the progress we’ve made to date, and grateful for the insights and feedback provided by our customers and accessibility community peers that are making it possible.

Special thanks to Brandon Biggs for sparking my interest (and raising my awareness!) in accessibility during that initial Follow Me Home. To Ethan Holliger for providing ongoing user feedback that has led to meaningful improvements for Mint customers. To Lucy Greco, a web accessibility evangelist at UC Berkeley, who generously shared her knowledge at an Accessibility Champion Lunch and Learn, and walked through the Mint iOS app to provide feedback. And, to Ted Drake, Global Accessibility Leader for Intuit’s Accessibility Champion program, for all of his support and guidance.

Want to come help us build accessible mobile apps at Intuit? Check out open positions at https://www.intuit.com/careers.