You can check if some features, like VoiceOver, are on. Experiences should not diverge too much. It could be used to avoid auto-hiding UI elements. iOS probably checks this to show search fields by default, without having to pull them down.
From the documentation:
isVoiceOverRunning: https://developer.apple.com/documentation/uikit/uiaccessibility/isvoiceoverrunning
You may also find interesting...
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.
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.
If you need to send announcement notifications that can step into each other, they will by default, interrupt ongoing announcements. But you can pass attributed strings as parameters too, letting you specify announcements to be queued.
