Please, don't use accessibility labels as ids for your UI tests. It can completely ruin the experience for VoiceOver users. There is actually an accessibility identifier property that you can use instead to uniquely identify your UI elements.

An app for booking flights has used the accessibility label property to uniquely identify elements, presumably for finding those elements on their UI tests. That means that VoiceOver will start reading something like “Plan underscore trip underscore ban underscore airport underscore description underscore label. Plan underscore trip underscore ban underscore origin underscore airport underscore gps underscore icon. Plan underscore trip underscore btn underscore airport underscore title underscore label”, instead of a more understandable sequence of labels, something like “From. London Gatwick”.

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

Grouping elements in SwiftUI is extremely easy! You can use the .accessibility(children: .combine) modifier. And that's it! It merges properties. For example, generating an accessibility label by joining the children's ones, separated by commas.

Too much data can overwhelm users. Very little is an incomplete experience. It is hard to find a balance on verbosity and the users may have different preferences. To help with this issue, the AXCustomContent APIs let you mark data as optional.

Created in Swift with Ignite.

Supporting Swift for Swifts