Here’s how to make your iOS App more user-friendly for visually impaired people like the blind by adding VoiceOver capabilities.

The profile

“Voice-over” is a screen reading ability that allows people to navigate the device’s interface without looking at the screen. Blind users rely on voice-overs to provide auditory feedback when using their iOS devices, but voice-overs aren’t just for the blind community. For example, some people with motion sickness may also choose to turn on the “voice-over” feature while riding in a car. The “voice-over” function is convenient for all kinds of people, and the blind rely on it more when using the device.

Using Xcode or pure code, you can make your APP “voice-over” in just a few steps. By making your APP accessible, you will reach a wider market and make it easier for anyone to use.

Test your APP by turning on the voice-over feature

To test the accessibility of the APP, let’s turn on the “Voice-over” feature and take a look at the interface. By using your APP under the voice-over feature, you’ll get a basic sense of its accessibility. First, go to Settings > General > Accessibility > Voice-over and turn on the voice-over feature. Then, open your app and use specific gestures wherever you want to test the voice-over feature.

This test also reflects which elements are accessible in the voiceover and which are not. It also tells you if the narration is viewed in a clear and logical order. Keep an eye out for elements that don’t support accessibility and make a list to add better accessibility support.

Use “Narrator” to browse your app

Testing the app with voiceover requires you to use a specific set of gestures for the Voiceover feature.

Here are five key commonly used gestures:

  • A left or right swipe jumps to the next or previous element
  • A double click on the screen is equivalent to clicking on the current element
  • A two-finger stand-alone screen can stop or resume voice
  • You can read everything on the screen with two thumbs up
  • Three finger taps to turn off or on the screen.

To learn more about gestures, see the user’s guide.

To fully recreate the blind user experience, test your app under the screen. As the name probably implies, the “curtain screen” darkens the entire screen. After opening the Screen, you can still use the Voice-over gesture, but you can’t see on-screen elements.

Now that you can open “Narrator” and know how to navigate your app, you’re ready to test your app.

Identify common accessibility issues

To test your app, check that you can access each element and that they are in the order you expect. Make a note of whether each element is accessible. Also, keep an eye out for features that are difficult to use under the “voice-over” feature. For example, returning to the app’s initial page, or sharing content with other apps or users, how can you do that using voice-over?

When testing your app, there are some common questions to be concerned about:

  • Add accessible information to the elements of your app. The voiceover does not recognize custom UI elements by default; you need to add additional accessible information to these elements.
  • __ groups the elements so that voiceovers traverse them in the correct order. __ voiceovers are read backwards by default. If you want voiceovers to iterate over elements in a different order, use element grouping to optimize. It makes sense for your app.
  • Add descriptive text to the “narrator” to read. __ A visual-dependent UI would look great, but might be unusable to a “voice-over” user. For example, the voice-over will not detect that a confirm button changes from gray to green when selected. Left untreated, the narrator might describe the element itself, not its current state. Make sure the narrator can read if the button is selected.

Now that you know what needs to be optimized, add better voice-over support to your app.

Optimize accessibility of your App

For elements that can’t be accessed with “voice-over”, first optimize their labels and hints.

  • The accessibilityLabel property provides a descriptive text that is read by the narrator when the user selects the element.
  • The accessibilityHint attribute provides additional hints for the selected element.

Labels are very important because they provide “voiceover” readable text. A good label should be concise but contain enough information. Notice that UILabel and accessibilityLabel are two different things. By default, the narrator reads out the text content of standard UIKit controls, such as UILabel and UIButton. However, these controls can also be individually set to accessibilityLabel to add more detailed information.

Hints are not always necessary and need to be context-specific. In some scenarios, the label already provides sufficient information. If you think there’s too much content in the Label, put some in the Hint.

To make sure the user understands the purpose of the interface, you see that you need to manually set some labels. Labels and hints can be set either through Xcode’s Identity Inspector setting or manually in the code.

Add labels and hints through the Identity Inspector

When using standard UIKit controls, you can set the Label and Hint in the Identity Inspector panel in Xcode. To improve Accessibility, make the current element accessible by checking Accessibility. For example, a music App’s play button should contain label and Hint as shown in Figure 2.

Figure 2: Identity Inspector Accessibility panel

Add labels and hints through code

Many times it is not enough to set labels and hints with Xcode. For example, when you use a custom UI component, the “voice-over” will not be read automatically. A similar problem occurs when you include a variable in a label. In these cases, you can only set labels and hints in your code. You first need to verify that the element is accessible, and then add the appropriate label and hint.

In order for an element to be accessible by a “narrator”, it needs to be defined as an accessible element.

score.isAccessibilityElement = true
Copy the code

An element’s label may change throughout its life cycle. For example, if a counter is used to calculate the score of a game, you want the content of the label to change when the score changes. You can set label and hint as follows:

score.accessibilityLabel = "score: \(currentScore)"
score.accessibilityHint = "Your current score" 
Copy the code

Simplify accessibility information

The “narrator” uses the orientation of the system language to determine the orientation of the traversing interface elements. For example, in English-speaking countries, “narration” is traversed from left to right, while in Arabic and Farsi it is read from right to left. If you stack labels vertically on the UI, or display text in a table, the narrator may not traverse the labels in the correct order. You can group the accessible elements in your code to ensure that the voiceovers are read in the desired order. For example, suppose you create an app with the title and content of Name and Email from top to bottom, as shown in Figure 3.

Because of their order on the interface, the narrator does not pronounce these elements together. To ensure that what the narrator reads is clear, these elements need to be grouped.

Figure 3: An example of how “narration” traverses elements, ungrouped and grouped

On the left, there are four labels, “narrator” read from front to back, in this case, left to right. Since every element is accessible to the “narrator”, the user experience is not great. On the right, the “narrator” reads the grouped labels in the expected order, so the interface is clear.

To group labels with code, first create a UIAccessibilityElement, and then add the information you want to the grouped elements. For example, group labels as follows:

var elements = [UIAccessibilityElement]()
let groupedElement = UIAccessibilityElement(accessibilityContainer: self)
groupedElement.accessibilityLabel = "\(nameTitle.text!) , \(nameValue.text!) "
groupedElement.accessibilityFrameInContainerSpace = nameTitle.frame.union(nameValue.frame)
elements.append(groupedElement)
Copy the code

Adding accessibility tags to each element and grouping them together will make your app more accessible to “voice-over” users.

On the,

  1. GroupedElement is inserted into the page view tree so that it does not destroy the view tree. The usual way to do this is to put “Name:” and “Maria Ruiz” inside a UIView, and to that UIView set isAccessibilityElement and accessibilityLabel.
  2. Accessibility is of social significance and economic value may be modest, so it does not receive much attention. The official has iterated several documents, this is the latest one at present, I searched it and it seems that there is no Chinese version, let’s translate it briefly, although the translation is bad, but it is also meaningful.