How to get started with Voice Over on iOS
What is Voice Over?
Voice Over is an accessibility feature that reads aloud the items that appears on the device screen. It helps your users to navigate and interact with your app by describing its content and giving useful context about each element.
Technology is most powerful when it empowers everyone.
I’ll cover the basics in this article to hopefully get you started on how to implement this capability in your app. The more developers are aware of accessibility features, the more it can benefits all of our users.
How to turn Voice Over on?
Voice over can be turned on under the accessibility settings. It can be worthwhile to learn how to navigate with Voice Over before turning it on though. You can also try the Voice Over practice in the settings as seen on the next image.
As a developer wanting to test this capability, I would recommend to test it through the Accessibility Inspector tool or by quickly turning it on through the accessibility shortcuts with the a quick triple click on your iPhone side button. The shortcut can be enabled under the accessibility settings. It’s also possible to enable or disable Voice Over with Siri by saying “Hey Siri, turn Voice Over off/on”.
Where to start?
By default UIKit already helps us leverage a lot of the Voice Over functionalities. If you use standard UIKit control like UIButton, UILabelor UITextfield, accessibility is already enabled by default since with isAccessibilityElement set to true. But what exactly will be read out loud to the user?
If you set text on your UIButton without touching any of the accessibility elements, Voice Over will read aloud that particular text to the user.
But if text is read out loud by default, what is the accessibilityLabel used for? Well, think for example about an image or a button that doesn’t have any text on it. How can Voice Over know what to read to the user? That’s where the accessibilityLabel comes into play.
This all makes sense, but if you look at the accessibility documentation, you’ll also notice an accessibilityIdentifier. This is particularly useful if you have any user interface automation like UI tests. If your application supports localization, your labels need to be localized to different languages. By using an identifier you can make sure you have a standard way to access that element on screen.
A friendly convention
One of the most difficult skills to acquire as a developer is how to name your variable and classes with a relevant name. Joke aside, it can indeed be hard sometimes. To help you through this accessibility quest that you might have just started on, it can be useful to know that there’s a naming convention that can be used to avoid typing down a-c-c-e-s-s-i-b-i-l-i-t-y each and every time time you create a variable for a label or an identifier. This naming convention is a11y. Why would you ask? Because there’s 11 letters between the first and last letter, and implementing accessibility in your app also makes you an ally of the cause!
When context matters
There’s multiple ways to give additional context on elements to your users, when reading the label isn’t enough.
Accessibility traits
Accessibility traits are an important feature to look out for when supporting Voice Over. Traits will add context to your elements so the users know what to expect. For example, it could be confusing for a user if by clicking on a text field they are brought to the app settings. One could also assume a button is always a button and would keep you inside the application, but what if this button brings you to Safari? In this case it could be more appropriate to use the Link trait. In short, traits are used to make the app more transparent to users.
Always make sure the traits you assign to elements properly reflects what the element does. This could mean disabling accessibility traits sometimes since some traits are enabled by default on standard UIKit controls. If the screen content is dynamic, make sure that the traits changes to reflects the new capabilities.
Accessibility hints
Another useful tool are Accessibility hints. They give supplemental information on actions that can be performed when the label isn’t self-explanatory. The label and the traits are announced first and after a short pause the accessibility hint will be spoken out loud.
An example could be on a shopping app that has an “Add” button. The accessibility label would be “Add” and the trait would be “Button”. By adding a hint we can let the user know that by clicking this button they would add this item in his shopping cart. Otherwise the user can’t know what it adds and where it adds it.
Accessibility value
The next useful property is Accessibility values. This is a localized string that contains the current value of an element. If we’re using our shopping app again, we could have a shopping cart view with a label of “Shopping cart”, but it’s accessibility value could read “5 items in the cart”. This cart view could also have a gesture recognizer that handles click event to bring us to the actual cart page.
Any children UI elements under this cart view need to have accessibility element set to false. If the parent view is being read with VoiceOver to the user, the children don’t have to be accessible since all the information is already read by the parent.
Navigation overview
Voice Over users have more than one way to navigate your app. They can use for example the Voice Over rotor to navigate headers, containers, and landmarks. Another way is by simply swiping left or right to navigate each element at a time, or by pointing a finger directly on the screen.
To facilitate navigation in your app, it could be necessary to group elements together with UIAccessibilityElement or by implementing UIAccessibilityActions or even custom actions. This can really help bring the application from good to exceptional!
For example, if we use our shopping app again, a shopping item cell could contain a lot of information like: a title, a description, a price, the colors, the fabric, the availability, an image, etc. A problematic experience could be that the user needs to swipe through all information in that item cell to be read out loud before reaching the next shopping item. If it’s the case, then extra steps are needed to ensure the proper level of details. This is a case by case situation so there’s not really a one size fits all solution.
Test your app like a Voice Over user would
One way to know if your application needs improvement with the Voice Over capability, is to navigate it with the screen curtain. You can enable this functionality by tapping three times with three fingers on your screen. This feature will make your iPhone screen dark, making it possible for you to test navigation in your app through Voice Over without relying on any visual cues. In other words, it makes you blind.
I would suggest to enable it and try to do some tasks in your app. Are you able to access all items and actions? Were you lost by trying to do those tasks? What could have helped you? A little by little goes a long way here.
Accessibility is everyone’s responsibility
Accessibility is human-centered topic. It’s not always easy or straightforward to implement but in the long term it can only help all of our users.
Starting to support accessibility features doesn’t take much more time than one would think. Once you know what to look for, it will take a couple minutes of development time to ensure it works. Maybe it won’t be an exceptional experience at first, but it’s always better to have a good enough experience in your app than a broken one. Then you can work your way from good to exceptional!
I hope this was helpful for you and that the next feature you implement you’ll ensure Voice Over users can enjoy your app too.
Take the longest road, it’s faster.
