Day 20
7 Jun 2022
An accessibility trait is the role of the component. Among other things, it gives the user information on how they can interact (or not) with it. When using VoiceOver, the trait is usually (not always) read after the accessibility label.
At the time of writing this tweet, there are 18 different accessibility traits: https://developer.apple.com/documentation/uikit/uiaccessibilitytraits
Some examples are: button, header, selected, adjustable or not enabled.
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.
With the attribute accessibilitySpeechPunctuation, you can ask VoiceOver to speak any punctuation marks in your attributed accessibility label, if that is what you want. Good for code snippets?
When using Voice Control, say: "Show names". You'll see all the accessibility labels for interactive elements overlaid on the screen. It will help you identify labels that can be improved, or actually missing. Labels are not just for VoiceOver.
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.
Content © Daniel Devesa Derksen-Staats on Accessibility up to 11! is licensed under CC BY 4.0. License details
