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.

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.

Some of you have asked me how you can support what I do. This would really help, and would be hugely appreciated:
Find these posts useful? Share them at work, on social media, or with anyone that might find them interesting. Let's spread the word!
Check out any of my apps or games: Xarra!, RetroRapid!, or Mestre!.
A download and a review go a long way. They're free by default. On the App Store, ratings and reviews really help more people discover them.
Finding any of them useful? If so, and if you can afford it, purchasing lifetime access to all features or subscribing lets me buy the coffee that keeps me caffeinated. Caffeine keeps me going to maintain the apps, bring in new features that I hope you'll love, and keep writing.

Custom actions work well with VoiceOver and Switch Control. It is also a way of speeding up navigation, and grouping all actions available for an item in a single place, with Full Keyboard Access. Focus an item and use the shortcut Tab (⇥) + Z.

The .selected accessibility trait indicates when an element has been selected. You’ll notice that VoiceOver announces “selected” before the accessibility label. You can find that in the system for the selected tab in the tab bar, for example.

You can add an observer to listen for changes in the content size category, in case it is more convenient than overriding traitCollectionDidChange(_:).
Content © Daniel Devesa Derksen-Staats on Accessibility up to 11! is licensed under CC BY 4.0. License details