Full Keyboard Access can be tested in the simulator! So convenient! You can enable it from Accessibility's settings in the simulator. And from there, you can navigate your app by just using your computer's keyboard.

Full Keyboard Access can be tested in the simulator! So convenient! You can enable it from Accessibility's settings in the simulator. And from there, you can navigate your app by just using your computer's keyboard.

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.

The Accessibility Inspector let’s you run an audit of the current screen in your simulator or device. It can find some basic issues like color contrast issues, touch target sizes that are too small, etc. It can also provide with fix suggestions.

Sometimes we may fail to convey to the user of things changing on the screen in a perceivable way. Toasts and similar should be announced. We may want to make clear that some content on the screen changed. Or we might want to update on progress.
Content © Daniel Devesa Derksen-Staats — Accessibility up to 11!