Introduction to the

On iOS, when we talk about accessibility, we usually mean the support for the system’s functionality — “voiceover.” UIKit components support “narration” in place, most of the time developers do not need to do special barrier-free to achieve basic compatibility, occasionally encountered some problems are relatively easy to deal with. It is recommended that developers first try out the voice-over feature to understand how blind users use it, and then consider how their app should be adapted. See the official article on how to use the “voice-over” gesture.

An introduction to

The properties associated with accessibility are added to NSObject, that is, every element on the page has these properties, including UIWindow. Here are just a few core attributes:

  • isAccessibilityElement
  • accessibilityLabel
  • accessibilityElements

The basic logic of VoiceOver is to recursively traverse all elements of the current page. If an element isAccessibilityElement == YES, read the element’s accessibilityLabel and so on. If an element isAccessibilityElement == NO, then its accessibilityElements are iterated over. Follow the general order of current system languages (left to right and top to bottom for Both Chinese and English).

So it’s pretty clear what we need to do:

  • If an element needs to be read directly, isAccessibilityElement is set to YES and accessibilityLabel writes the appropriate text
  • If an element is not read out, but its child elements need to be read out, set the current element isAccessibilityElement to NO, and the child elements that need to be read out refer to the previous one
  • If you want to control the order of VoiceOver traversals, set accessibilityElements

Since system controls are handled by default, and VoiceOver’s default reading order is usually not a big deal, there aren’t many scenarios that developers need to specifically accommodate. This averages out to a few lines of code per page.

After all, blind people are a minority group, and most applications are not barrier-free. If an application’s main scenario can do all of these things, it is already good in terms of accessibility.

Some specific questions

1. Manually focus

Sometimes you should focus your VoiceOver on the pop-up view

2. Translucent layer

Also similar to the pop-up prompt, there is usually a translucent mask under the pop-up, the content under the mask can not be clicked. VoiceOver performs poorly at this point, being able to read the content underneath the mask but not being able to click. In this case, you need to set the accessibilityViewIsModal property for the mask layer, which will make the peer view of the mask layer not respond to VoiceOver, but the child view of the mask layer can respond. Note: This property also works for Windows.

[Prevent VoiceOver revealing views that are beneath a larger transparent view](stackoverflow.com/que…)

3. The hidden elements

Sometimes when you set a view to Hidden, it’s no longer shown on the UI, but VoiceOver can still read it. At this point you can use UIAccessibilityPostNotification (UIAccessibilityLayoutChangedNotification, nil) mandatory update VoiceOver.

Reference: VoiceOver Controls are selectable when hidden

Recommended reading

IOS Accessibility Programming Guide