You can check if VoiceOver is running but you can also get a notification to act in case that changes, while the user is using your app. As seen before, you rarely want to do significant changes in the experience when VoiceOver is on.
But this use-case presented by @djembe from @NetflixEng at @appbuildersch is an excellent example of inclusive design. When VoiceOver is on, they bump the Audio Described "genre" to the top of the list. Brilliant!
https://m.youtube.com/watch?t=981&v=NQjBcZuts&feature=youtu.be
These series of tweets tend to be fairly technical but as John says, a big part of creating great accessible user experiences is about "being kind", about caring about your users and customers to come up with great features like this one.
You may also find interesting...
Do you know when a UI element is greyed out to show that it is disabled? Yes, there is an accessibility trait for that too: .notEnabled. VoiceOver will say “dimmed” after its accessibility label and Voice Control and Switch Control will skip it.
Hacks are accessibility’s worst enemy. An example. There is a ‘trick’ floating on the internet: if you want a button with an icon to the right of the text, set the semantic content attribute to force right to left. Great way to create focus traps.
When implementing a UISlider, it is a good idea to consider how much the slider value should change when swiping up/down to adjust it. It might not always make sense to do it in 10% increments, which is the default behaviour. Could be because the value at those intervals doesn't make sense, or feel random, or because it wouldn't provide the user with a fine enough control being able to go through the whole slider in just 10 swipes. It user will still be able to adjust the slider to any value by double tapping and holding and then moving the finger left or right, bypassing VoiceOver gestures. VoiceOver announces the new value as it changes.
