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.
You may also find interesting...
If you want to know everything about how to "Tailor the VoiceOver experience in your data-rich apps" with the Accessibility Custom Content API, there is a WWDC21 session. https://developer.apple.com/videos/play/wwdc2021/10121/ When implementing accessibilityCustomContent, for any supplementary information, it returns an array that VoiceOver will announce in that given order. The value of the AXCustomContent first, then the label. Users can configure in VoiceOver's verbosity settings if it should say that there's more content available, or play a sound hinting that there is, or simply do nothing. So it should really be optional content as users might miss it.
"We have one job, and that's to make our apps work. And if you are not implementing accessibility features, you are forgetting about making it work for a lot of people" @NovallSwift Couldn't have said it better! https://x.com/novallswift/status/1328387659744505856
Manual testing is crucial. And therefore, reducing friction to let you start your testing process can be a huge help. Selecting some accessibility shortcuts will do that, putting most of iOS' accessibility features at a triple-click of a button.
Content © Daniel Devesa Derksen-Staats on Accessibility up to 11! is licensed under CC BY 4.0. License details
