When setting isAccessibilityElement to true, assistive tech like VoiceOver will stop looking for other accessible elements in that view hierarchy. So if we make a view accessible, its subviews, including buttons and labels won't be accessible.

A tweet is composed by several UIKit elements: A UIImage for the profile picture; maybe 3 UILabels for name, username and date; a UIButton for more options; probably a UITextView for the text of the tweet; 4 more UIButtons for comments, retweets, likes and share, etc. Just with this elements (because all of them have the isAccessibilityElement configured to true by default), VoiceOver would focus in 9 or so UI elements. If we configure isAccessibilityElement to true for the container view, VoiceOver will see the whole thing as a single accessibility element, and everything else inside the view, will be ignored.

You may also find interesting...

When making charts accessible, sometimes you may have just too many data points for the user to have to go one by one through all of them. In those cases, you can create accessibility elements that represent meaningful chunks of the graph.

Even when setting a view as modal for accessibility, you may notice that VoiceOver's focus stays in the same place, instead of moving to the presented view. You can post a screen changed notification and pass the view that should get the focus.

Configuring the header accessibility trait, when appropriate, is one of my favourite accessibility quick wins. In this example, you need a single swipe down, instead of 12 swipes to the right to get to from Podcasts to Artists, in the app.

Created in Swift with Ignite.

Supporting Swift for Swifts