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...
The .accessibilityElement(children: ) modifier with the .ignore argument does a similar thing to set the container view to be an accessibility element in UIKit. It is the default argument, so you can just say .accessibilityElement(). Because of this, you'll need to use other modifiers to make it accessible and manually configure an accessibility label and value, traits... when necessary. https://developer.apple.com/documentation/swiftui/view/accessibilityelement(children:) https://developer.apple.com/documentation/swiftui/accessibilitychildbehavior/ignore
When configuring a largeContentImage or adjustsImageSizeForAccessibilityContentSizeCategory, it is important to use a pdf asset and preserve the vector data so the icons are crisp at any size.
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.
