In SwiftUI there is a very useful modifier accessibilityElement(children:), that will do very different things depending on the AccessibilityChildBehavior passed as a parameter. There are three options: ignore (default), contain, and combine.

If a view has isAccessibilityElement to true, assistive tech won't look for any of its subviews. That means that if there are any buttons inside, they won't be accessible. You can add custom actions to that element though.

The equivalent of using a .semanticGroup accessibilityContainerType in UIKit, would be to use the .accessibilityElement(children: ) modifier with the .contain option in SwiftUI. Here's a refresher with some use-cases: https://x.com/dadederk/status/1558790851496742914

Apple asks us to consider the combine behavior, before using ignore, for .accessibilityElement(children: ). And for good reason, if combine works, and later on you decide to change the UI, the accessibility attributes will be updated for you.

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 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.

Creating UIAccessibilityElements, combined with a semanticGroup accessibilityContainerType, can also help you make components as complex as charts accessible. Example from "Bring Accessibility to Charts" WWDC21: https://developer.apple.com/videos/play/wwdc2021/10122/

Sometimes you can create your own accessibility elements from scratch to group elements too. Perhaps because they're not contained in the same superview. You can combine these elements' frames and provide a suitable accessibility label.

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.

It is possible to change the traversing order of accessibility elements by configuring the accessibilityElements array. You should try to avoid it, but one good reason for doing it is if the default order is illogical because of the visual layout.

What is the difference between isAccessibilityElement and accessibilityElementsHidden? The first one makes the view not accessible, but its subviews can still be accessible. The second one hides the view and all its subviews from assistive tech.

If you need for a view (and all its subviews) not to be focusable by assistive tech like VoiceOver, you can set its accessibilityElementsHidden property to true. This isn't needed very often, but it can be useful for certain custom experiences.