Accessibility Labels are not just for VoiceOver, and Accessibility User Input Labels are not just for Voice Control. The latter will also help Full Keyboard Access users to find elements on the screen by different names. Good API design!

When using Voice Control, say: "Show names". You'll see all the accessibility labels for interactive elements overlaid on the screen. It will help you identify labels that can be improved, or actually missing. Labels are not just for VoiceOver.

A quick way for turning on, or off, VoiceOver is by using Siri. Say something like: "Hey, Siri! Turn on VoiceOver", and you'll find yourself using VoiceOver in no time. You can also do the same with other technologies like Voice Control.

One thing I find very useful when testing (or doing demos!) is to have VoiceOver's caption panel enabled. It shows constantly at the bottom of the screen and you can see exactly what VoiceOver is saying.

This is my favorite way of testing VoiceOver. Pick a flow in your app. Turn VoiceOver on. Triple tap with three fingers on the screen to enable Screen Curtain. The screen goes off but you can still navigate your device with VoiceOver.

In SwiftUI you won't find the .notEnabled accessibility trait. Instead, you can just configure a view as such with .disabled(true), and pass false to enable it. VoiceOver will announce it as "dimmed". https://developer.apple.com/documentation/swiftui/view/disabled(_:)

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.

When creating AXCustomContent objects for accessibilityCustomContent, you can specify the importance of the data. If it is high, it will always be presented by VoiceOver. You could potentially ask the user if that data is of importance to them.

When something is focused with VoiceOver, if you double tap on the screen, it will be like interacting with the centre of the focused element. If you need to change that, you can customise the accessibilityActivationPoint. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilityactivationpoint

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 @appbuilders_ch 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=N_QjBc_Zuts&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.

VoiceOver announces "Tab bar" or "Toolbar", the first time you select an element in one of these components. If you are implementing your custom versions of these, you can mirror this behaviour, as seen in previous tweets. https://x.com/dadederk/status/1558045414082871298?s=20&t=LA95j22apvWsUqShqWGBzA

Have you noticed that the first time you select an element on Apple Podcast's mini player, VoiceOver says "Mini player", and then, it describes the selected element? It gives the user more context on what "feature" those elements belong to. This can be achieved in UIKit by configuring the accessibility container type of the mini player with .semanticGroup and giving it an accessibility label, in this case: "Mini player". https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilitycontainertype https://developer.apple.com/documentation/uikit/uiaccessibilitycontainertype/semanticgroup