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.
You may also find interesting...
When thinking about accessibility labels and values, it is easy to miss adding information or state that are represented by little visual cues and icons: a checkmark indicating something has been played, a down arrow indicating a downward trend...
The Accessibility APIs are generic and flexible. They're not just for VoiceOver. If you implement them right, you can do it once and it will very likely work great for VoiceOver, Voice Control, Switch Control, Full Keyboard Access, and more. That's why, to start with, we tend to focus on VoiceOver, the same way you may focus on keyboard navigation for the web. A great VoiceOver experience will get you most of the way to a good experience with the other assistive technologies. We've seen one example with Custom Actions. One implementation works for: VoiceOver: https://x.com/dadederk/status/1550099327053451266 Switch Control: https://x.com/dadederk/status/1551236244088279040 Full Keyboard Access: https://x.com/dadederk/status/1551874732504629249 And Voice Control: https://x.com/dadederk/status/1552253520182640645 Of course that doesn't mean you don't have to test and check how the experience is with the other technologies. But before feeling overwhelmed, or for small teams, making sure your app works for VoiceOver is a great start.
There is an accessibility trait for defining something that represents a custom keyboard's key: .keyboardKey. It allows VoiceOver users to change the typing mode to Direct touch typing. The calculator app or an access pin pad, are some examples.
Content © Daniel Devesa Derksen-Staats on Accessibility up to 11! is licensed under CC BY 4.0. License details
