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.

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.


Imagine playing a piano with VoiceOver. You'd have to find the key you want to play and then double tap. It would be a very difficult experience. With the .allowsDirectInteraction accessibility trait, VoiceOver passes through touch gestures. Use carefully! And only when it really makes sense to be able to handle controls directly with touch. Other examples could be a drawing app or some games.

All the accessibility capabilities you can check for, have counterpart notification names you can observe in case the user changes its preferences while using your app. https://x.com/dadederk/status/1577435144129892352

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!