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 presenting a UI component that overlays the existing UI, you may have found that VoiceOver starts to randomly jump between the overlaid UI and the elements underneath. To avoid that, you can set its accessibilityViewIsModal to true. When setting the accessibilityViewIsModal to true for a view, VoiceOver will ignore its sibling views, treating it as if it was a modal. Useful when presenting custom popups, popovers, modals, action sheets, etc. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilityviewismodal

You can create your own accessibility elements from scratch. One use-case for doing that is when you do some custom drawing instead of building your UI using or relying on UIKit components. A circular progress bar, could be an example.

Support both orientations, if possible. I know not even iOS itself does it, but it hasn't always been like that. You'll create a more robust UI that will be easier to port to iPadOS. And especially, don't force your users to rotate their devices.

Created in Swift with Ignite.

Supporting Swift for Swifts