Approximately one in seven people in the world have some accessibility issue. To help you build fully inclusive digital products all users will be able to interact with, we’ve put together practical iOS app accessibility guidelines.
In our daily work as a digital agency, we always strive to provide better value to our clients and improve the experience for the end-users, the people who will interact with the products we build. In line with this, we have been attentive to the state of accessibility in mobile apps for a while.
Until recently, we haven’t been able to find a clear and systematic way of adopting such features, let alone designing and developing with accessibility in mind from the get-go. It became clear that we needed a more centralized, generalized set of accessibility guidelines to provide project teams with concise information on the best practices, technologies, and features. These would also help them adapt their processes so that accessibility is built-in at the very core of any product.
By designing and building with accessibility in mind, we enable more people to use the apps they want.
We directed our efforts toward creating such guidelines so we could help both ourselves and the community. At the same time, we wanted them to be the starting point for setting a new standard for accessibility in mobile apps.
This blog post will focus on iOS app accessibility guidelines, which are a part of the Accessibility mobile standards found in our Accessibility handbook. If you’re still new to the initiative, it will help you get better acquainted with it. When you’re ready to dive deeper into the topic, the full guidelines are freely available for you to explore and start using on projects.
iOS accessibility features – the first step to building an app for everyone
When setting out to build an accessible iOS app, you’ll notice that Apple already offers amazing tools and techniques that we can use. Without them, achieving a satisfactory accessibility level would be almost unimaginable.
Popular features like Dynamic Type or VoiceOver support are usually the first that come to mind. However, these are just some of the tools available in native Apple SDKs that allow us to achieve the desired goal: build an app that can be used by anyone who needs it.
In order to successfully use these tools, we first need to understand how they work. Our first step should be to become familiar with all of the mechanisms for making an iOS app accessible. These mechanisms are divided into four main categories according to the sensory aspect they support: vision, mobility, hearing, and cognitive.
Vision iOS accessibility features
There are a variety of features in iOS that help users with different visual impairments interact with their devices.
For example, VoiceOver is a full-featured screen reader that enables people to grasp an app’s content without having to see the screen. It allows users to interact with UI elements in over 60 languages. Speech Synthesizer can read out the selected text from any app in over 60 languages. Users can customize the accent, speaking rate, and other options. DynamicType lets users choose the scale of the text on their device.
iOS also has a great variety of display customization options, including Bold Text, Increase Contrast, Reduce Transparency, Smart Invert, Differentiate Without Color, On/Off Labels, Button Shapes, Dark Mode, and Reduce Motion.
When it comes to audio and video, there is built-in support for captions and audio descriptions during media playback.
Mobility iOS accessibility features
For users who have motor or physical limitations, iOS offers several solutions to help them use an app.
Voice Control allows users to navigate through an app’s UI using only their voice, by saying commands like “tap”, “swipe”, etc. Switch Control enables navigation using different adaptive devices like joysticks, keyboard buttons, trackpads, and the like, to simplify the interaction to a more concise set of available actions.
iOS also has keyboard support to provide even more flexibility in interactions, while Haptics provide quick and understandable feedback to a variety of users.
Hearing iOS accessibility features
Multiple features are in place to help people with hearing difficulties, including translation, hearing aid support, captions, sound recognition, background sounds, and more. Captions allow people to watch movies and videos with closed captions or SDH subtitles.
Many leading manufacturers have integrated their cutting-edge hearing devices with iOS, allowing users to easily control their aids, for example, to set an audiologist-suggested environmental preset.
Cognitive iOS accessibility features
There are several built-in technologies on Apple devices that can help users learn or communicate more easily, including Guided Access, captions, word predictions, and SafariReader. Guided Access can help users stay focused on the task at hand by disabling some parts of the app, which can be really beneficial for people with autism or other attention and sensory challenges.
Once we know what we can do, we need to figure out which subset of these features our app needs. It doesn’t mean that you should do the bare minimum, but actually just the opposite.
Define your target audience as clearly as possible and see if any group of people is excluded from using the app. Think about whether your app brings value to those people. Only if the answer to the first question is “yes” and the answer to the second question is “no”, should we consider dropping some accessibility features that would only be relevant to that group of people.
In all other cases, we should get the most out of the accessibility mechanisms available so we can enable all our users to interact with the product.
Implementing features is easy with iOS app accessibility guidelines
Having come this far, you might be thinking: “OK, but does my app need accessibility?” The answer is yes, it does. Every product can benefit from accessibility features, especially if they are ingrained in the product’s original design. This becomes even more apparent when you take into account that approximately one in seven users have some accessibility needs, which is a substantial percentage of the people who will use your product.
The next step would be to define which features should be included and how to get the most out of them. This is the point where we found ourselves looking for some concrete directions, which finally drove us to create our own. In Accessibility mobile standards, we give a breakdown of several principles we all need to consider when designing and developing with accessibility in mind.
The concept was inspired by the WCAG, which have long been the gold standard for accessibility on the web. If you want to know more about WCAG levels and principles, you’ll find a more detailed explanation in our guide to building accessible digital products.
Our accessibility guidelines are an open-sourced, community-driven, supported, and maintained knowledge repository – a benchmark for all apps that support accessibility features.
In the guidelines, we cover multiple accessibility features and their uses, as well as ideas on how to implement them. This can help you decide which ones to use your product, and you’ll immediately have some concrete examples to make implementation easier.
Let’s say you are working on an app that plays audio or video content. Chances are, a percentage of your users will have hearing difficulties. One way you can provide them with a better experience is to add captions. If you are using Apple’s native AVPlayer from AVFoundation, this is really easy to do as it automatically supports captions out of the box. All the user needs to do is enable Closed Captions + SDH in their device’s Accessibility Settings, and you can guide them there from the app with a couple of simple instructions. You can check the status of this feature via UIAccessibility.isClosedCaptioningEnabled. If it’s off, display a message to the user explaining how they can access this setting and enable it.
Not all accessibility features are interactive, though. Some are passive and simply help users know where they are within the app at all times, so they can get a better grasp of the app’s navigational hierarchy. It’s really easy to achieve this by setting the navigationItem.title property to some meaningful text, so that features like VoiceOver can read it out and let users know where they are. If you place this at the start of your view lifecycle, for example, in viewDidLoad, you achieve even better accessibility. The VoiceOver screen reader will read it out first, before going through the contents of the screen. Not using the default navigation item title? No problem – just set the accessibilityLabel property of whichever custom view acts as your title and the effect will be the same.
You will find these and many more examples, principles, and scenarios covered in the Accessibility mobile standards repository. Look around, get to know the materials, and feel free to contribute or contact us if you have any questions or suggestions. We always appreciate quality feedback!
Accessibility is an investment, not an additional cost
Having covered the “what” and the “how” of iOS accessibility best practices, the question that probably comes to mind to many are the costs involved. How much does it cost to build an accessible product in comparison to a non-accessible one?
Think of it like this: do you think about the cost of differently-styled UI elements that represent buttons and text? Of course not, that distinction is an integral part of UX design. The user has to be able to easily recognize what parts of the app are interactive and how they can interact with them.
It’s the same with accessibility. The difference is in how we define the user – is it a typical one or any user, potential limitations and issues included? If we broaden our way of thinking and account for more of our users, we see that accessibility is also an integral part of the product, not something that is featured as a separate entry on the “costs” list. After all, more users is something anybody launching a commercial digital product is aiming for.
Accessible apps can be used by a wider audience. They provide a better experience for more people, while also helping your product stand out from the competition.
With all of the previously mentioned mechanisms provided by Apple, and community resources like our guidelines, you will soon realize that you can get accessibility virtually for free.
Every user deserves an equal opportunity to use digital products
We firmly believe that everyone deserves an equal opportunity to use digital products. In light of this, accessibility cannot be an afterthought. We need to stop thinking about it as an additional feature, or something that is “nice to have”, and start making it a regular part of our strategy, design, and development processes.
We’ve now reached a point in our work where we believe that choosing to disregard accessibility would be simply irresponsible. We have everything at our disposal – the tools, the knowledge, and the ability to make better apps for everyone. By refining our guidelines and developing them further, we hope to soon have a framework that will enable us to do just that.
