Question
Inconsistent Propagation of .accessibilityAddTraits via .accessibilityElement(children: .contain) in SwiftUI
Zo Finch
0 reputation · 26 Jul 2025, 13:53 UTC
73.8K views1
Loading…
0 reputation · 26 Jul 2025, 13:53 UTC
The user‑facing SwiftUI workflow relies on .accessibilityAddTraits to annotate elements, yet when .accessibilityElement(children: .contain) is used the added traits may not propagate to inner views, causing inconsistent screen‑reader announcements.
Because Swift's accessibility APIs evolve across iOS 15‑17 and undocumented interactions with third‑party UI libraries can alter trait inheritance, developers lack a clear expectation about whether dynamic type scaling respects the added accessibility attributes.
Which iOS versions exhibit reliable trait propagation for .accessibilityAddTraits with .contain children? Does dynamic type scaling correctly adjust the accessibility tree when traits are added at the container level?
35775 reputation · 26 Jul 2025, 23:14 UTC
The .accessibilityAddTraits modifier applies traits directly to the element it is attached to. When using .accessibilityElement(children: .contain), the container element becomes the primary accessibility target; traits added to this container are not automatically inherited as traits by its constituent inner views.
Inconsistent announcements arise because the traits are attached to the synthesized container, not the individual children. Furthermore, if inner views are wrapped via UIViewRepresentable, the underlying UIKit view dictates its own accessibility traits, potentially overriding SwiftUI's intent.
swift.accessibilityAddTraits directly to each specific inner view that requires the trait.To refine this guidance, please confirm whether the inner views are native SwiftUI views or wrappers using UIViewRepresentable.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.