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.
You may also find interesting...
When building custom components, or if not relying on UIControl's attributes to configure state, it can be easy to forget to specify the right accessibility traits. These are indispensable for a good experience with VoiceOver, Switch Control...
Test manually. Familiarise yourself with different assistive technologies. I find it useful to start with VoiceOver but check out Voice Control, Full Keyboard Access, and others... Remove friction, configuring shortcuts can help. Merry Christmas!
Accessibility Labels are not just for VoiceOver, and Accessibility User Input Labels are not just for Voice Control. The latter will also help Full Keyboard Access users to find elements on the screen by different names. Good API design!
