Sometimes you want to prioritise ease of navigation, and that's when configuring isAccessibilityElement to true on a container view makes sense. This is especially true in table/collection views and with complex cells with lots of elements.
Take the example from a tweet (from Day 62's tweet). If the tweet has 9 accessible elements, you'd need 9 swipes to the right to go to the next tweet in the list. But ideally, I single swipe should be enough.
https://x.com/dadederk/status/1549417799746994177
On the other hand, for the detail screen for a single tweet, you want to optimise for ease of access to each one of the elements, instead of navigation. In that case it would be better for the tweet view not to be an accessibility element.
You may also find interesting...
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.
Potential benefits from grouping logical pieces of information and moving buttons to custom actions: reduce redundancy (by removing repetitive controls) and reduce cognitive load (by making easier to know what item will be affected by each action)
@BeMyEyes, founded by @hjwiberg, enables people who are blind and low vision to identify objects by pairing them with volunteers from around the world using their camera. Winner of an Apple Design Award 2021 for Social Impact.
