It can be overwhelming getting started with accessibility in Apple iOS. The operating system has so many features, tools, and APIs. This is where the action plan will be helpful. The plan has three main points: VoiceOver, Dynamic Type, and good practices.
Dani recommends focusing on VoiceOver. However, this doesn’t mean you shouldn’t test your app with the keyboard, switch control, or voice control. The underlying APIs to implement a good VoiceOver experience are the same across all these technologies. If you implement a good VoiceOver experience, you’ll probably have a good experience with the other ones.
Dynamic Type makes it possible to specify up to seven different text sizes for different apps. You can also add five extra accessibility sizes. Many people who use Dynamic Type don’t identify as disabled or that they’re using assistive technology. It’s an important reminder that making apps accessible benefits everyone. Good practices refer to things that are not related to iOS technologies like color contrast and touch target sizes.
By the way, did you know that the first iPhone was not accessible at all? If you’d like to know the story of 36 Seconds That Changed Everything, check out this audio with a full transcript from Shelly Brisbin.
VoiceOver
VoiceOver is the screen reader that comes installed on most Apple devices. While using an iPhone, you can move your finger around the screen and VoiceOver will announce what you touch. Anyone not using VoiceOver typically only has to tap an item once to interact with it, such as turning a feature on or off.
When VoiceOver users tap once, VoiceOver says what they’re selecting. Interacting with the iPhone running VoiceOver requires tapping twice. Another important thing to know about interacting with VoiceOver is that users often swipe right to go to the next element. They swipe left to go to the previous one.
The first thing to know is that a single block of text can contain four properties. For example, you use an app to rate conferences. There’s a text field with the name of the conference. Next to it is a rating with five thumbs up. In VoiceOver, it’ll say something like “Rating 5 of 5. Adjustable. State how much you like the conference.”
In this example, the label is the rating, which is the name of the component. The value is 5 of 5 and this can change as it’s adjustable, which is an accessibility trait. The part about “rating how much you like the conference” is a hint. This is optional and you want to design to prevent the need for a hint.
The main issue in an iOS app is unlabeled buttons consisting of just an icon. If the button has an icon and text as a title or just a title, the accessibility label gets inferred from that text. But if it’s just an image, then you need to configure that explicitly.
Otherwise, VoiceOver will just say, “Text button.” Sometimes, VoiceOver will try to figure out what the button does. And it will say something like “Close button,” but that’s not a great experience. It’s just one line of code. You have to consider other things like if a button contains meaning.
Another important trait is the heading. Everything that looks like a header should have the heading trait. It helps the user browse the screen and quickly find different sections. You can combine a heading with another accessibility trait such as a button.
After you select and configure labels and traits correctly, one issue that happens a lot is that VoiceOver doesn’t group things logically, known as semantic views.
There are three steps to good semantic views:
- Grouping
- Configure the properties: label, value, traits, hints, etc.
- Custom actions
SwiftUI is a user interface toolkit that can do all three steps with one line of code. It’s not possible in every case, but it’s worth testing to determine if it makes sense.
Dynamic Type
Dynamic Type is for both small and large text sizes. It also looks at user preferences. Be aware when you get to the maximum size, all the tiles are the same size and you can still have a sense of hierarchy. It’s super easy to implement as it’s a matter of selecting a font based on style. Nonetheless, it will still need design considerations. As you increase the text size, the styles get closer and closer together.
Something you want to know is that there’s a property that lets you say a label is going to automatically scale to the text size selected by the user. If you don’t have the property and the user changes the settings while using the app, it’s not going to adapt. The only thing to do is to close and reopen the app. If this property is set to true to adjust the font for the size category, then it will automatically adapt when the user changes their preference.
A cool thing you can do with dynamic type is autolayout. For instance, you could be using a device that’s 13 inches in landscape. Having a line of text going from the left edge of the screen to the right is too long. Add multiple lines and it adds friction to the reading experience. Fortunately, there’s a readable content guide that handles that for you to prevent the width problems.
You can make it so images adjust automatically when the user uses an accessibility text size. Dynamic Type is not that difficult, but all layouts may not be designed with large text sizes in mind.
An example you can see everywhere is a table view style that has an image and some text. The text doesn’t have the whole width of the screen. And that’s the problem with large text sizes. But in iOS, you can check if the user is using an accessibility text size.
A useful trick is if you have what is called a stack view, that is a horizontal stack view, with an image on the text. If the viewer wants to use the accessibility text size, then switch the text to be vertical on the text. The image is going to come first, and then underneath the image you have the text.
This has two benefits. It lets the text go from side to side to the screen, plus you can increase the number of lines. Now you can grow as much as you want.
And the other trick that can help you with Dynamic Type is when you have a layout that has multiple columns. Like a weather app with two columns for indicating things like the UV index or sunset time or the wind or the rainfall. If the user is using a text size that is larger than extra-large or it’s an accessibility text size, then change it from two columns to one.
Good Practices
Color contrast ratios are important. Apple has a color contrast checker that shows the color contrast ratio and whether it passes or fails for three different sizes. White over black, for instance, has a 21:1 contrast ratio and passes for three text sizes. Then dark grey over black has a 4.5:1 ratio, which passes two out of three sizes. Then a light grey over black has a contrast ratio of 2.9:1, which fails everything.
Another good practice is having a touch target size of at least 44 points minimum. Almost everyone has encountered a time when they try to tap a button in an iOS app and they have to try it many times before they finally hit the button. In most cases, the button doesn’t have to look different. It’s the size of the button that’s small.
When you compare two images of a player, they are the same size. The only difference is the buttons are less than 44×44 points on one screen. The other has more than 44×44 points. The only difference is the bounding boxes are larger and creates a better experience.
Another example is the lack of multimodality. This means showing important information in just one mode, which could be color, shape, sound, or haptic feedback. But a combination of these expands the number of users who can perceive the information.
A good example of this is the shuffle button on the Spotify app. When it was off, the button was white. When it was on, the button turned green. But that’s hard for some users to perceive the differences between the two states on color alone especially those who are colorblind. The designers fixed this but adding a small dot under the shuffle icon when it was in the on state.
The next tip is to honor the user’s settings. When iOS 7 came out, Apple dropped skeuomorphism for the new flat design most apps use now. Back in the day, apart from being a revolution in how apps looked on the phone, it was a big step back for accessibility.
That’s because the fonts were super thin. The color palette had poor contrast. There were lots of transparencies, and lots of animations, and some users didn’t feel like iOS 7 worked for them. As a result, Apple found a way to fix that in iOS 8 by adding a set of user preferences. Users could select bolder text or larger text, on/off labels for switches, reduce transparency of the apps, and reduce motion.
Before dark mode was a thing, iOS had invert colors. Most of the iOS apps had a white background and black text or grey text on a dark background. Some users found it hard to read the app. So, they used the invert colors feature to change it from white text on a background. It was easier to read. However, when you invert the colors, it inverted everything including the images that you wouldn’t want to invert.
Then Apple introduced smart invert colors. This gives developers the opportunity to opt an image out of being inverted. While the name is smart invert colors, it still requires the developer’s intervention in telling it what not to invert.
The Plan
The plan to create accessible iOS starts with VoiceOver. It doesn’t mean you don’t have to think about the other technologies and test them. If you’re just starting and feel overwhelmed, then focus on VoiceOver along with labels, traits, semantic views, and its snowball effect. It was the first of these technologies to be introduced. Many iOS engineers have gotten into the habit of testing with VoiceOver.
Dynamic Type with its text, images, and alternative layouts is important. It has design considerations and it’s one of those things that if you do right from the beginning, it’s not hard to do. However, if you want to adapt a whole app to use large text sizes, then it’s a nightmare. This is when accessibility can gain a reputation for being hard.
And finally, good practices are things you need to keep in mind when implementing something new. These good practices include color contrast, touch target sizes, multimodality, and honoring the user’s settings.
In 2009, just after the first iPhone was introduced, Phil Silver came onto the stage to present VoiceOver. He spoke for 36 seconds about accessibility in iOS. And that’s why the name of the aforementioned documentary is “36 Seconds That Changed Everything.” There was no live demo and 36 seconds is not much. But it changed the iPhone forever. VoiceOver was the first feature you could zoom the screen. There were two or three more features. But they were basic.
The point is that it’s progress over perfection. If you feel overwhelmed, remember Apple had an inaccessible iPhone from day one. It took two years for them to present the first feature. Now they’re just one of the leaders of the sector. You have to just start with something and be persistent.
It’s not a one-day job. It’s not a one-person job. It’s something that you just have to get used to. You practice, and it becomes second nature. Actually, you quickly realize iOS has many great APIs and many great tools. A lot of times, big problems can be solved with a couple of lines of code.
The problem is when you leave it all to the end. When someone comes to you and asks how to make something accessible, don’t give them a list of 50 items. That will paralyze them and they will think there’s no time to do it. However, if those 50 items are 50 lines of code, then it’s not much. Often, people don’t know about it. Accessible development is a 365-day job.
Resources
- Dani’s thread of tweets for 365 days
- #365DaysIOSAccessibility hashtag on Mastodon
- #365DaysIOSAccessibility hashtag on LinkedIn
- 36 Seconds That Changed Everything from Shelly Brisbin
- Apple accessibility hub
- Sommer Panage is an inspiration to Dani. Follow Sommer on Twitter or Follow Sommer on Mastodon
Video Highlights
Select any of the bullets to jump to the topic on the video.
- Introduction
- The plan to create accessible iOS apps
- VoiceOver
- Dynamic Type
- Good practices
- Q&A with Dani
Watch the Presentation
Bio
Daniel “Dani” Devesa Derksen-Staats has his dream job as an iOS engineer on Spotify’s amazing Accessibility team. He has previously loved working at Skyscanner and the BBC, where he learned a ton about how to make iOS apps more accessible. Sometimes he lets Xcode have a break and spreads the love for accessibility at conferences.
Author of the Developing Accessible iOS Apps book, he keeps himself busy by writing a daily tweet about accessibility and iOS with the hashtag #365DaysIOSAccessibility Follow him on Twitter at @dadederk.