When thinking about accessibility labels and values, it is easy to miss adding information or state that are represented by little visual cues and icons: a checkmark indicating something has been played, a down arrow indicating a downward trend...

Convey important information in multiple modes (sounds, haptics, colour, iconography, messaging...) so no-one misses it. Take Spotify's shuffle button. It is green when on, white when off, but it has also a dot indicator. https://wearecolorblind.com/examples/spotify-shuffle-and-repeat-buttons/

accessibilityActivate() lets you capture a VoiceOver double tap. This is useful if you are creating a custom component you interact with using complex gestures or VoiceOver navigation gestures. An example: slide to unlock. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilityactivate()

In Objective-C accessibility traits are a bitmask. Some devs find tricky to work with them using bitwise operations. In Swift they conform to the OptionSet protocol that conforms to SetAlgebra. That means you can simply insert/remove traits.

Accessibility values are about state. Using them appropriately will make the experience better for Voice Control users. Think of a repeat button (values could be: off, one or all songs) or a notifications tab (value could be: x new items). For more on accessibility values, check out this fantastic blog post from @MobileA11y with info on the APIs (UIKit, SwiftUI), accessibility attributed values, WCAG, or some more examples (text in a text field, value on a stepper or slider). https://mobilea11y.com/blog/accessibility-values/

The .summaryElement accessibility trait causes VoiceOver to announce that element when the app starts. The element won't get the focus though, and the order is not affected. A candidate for this trait could be the rings info in the Activity app.

There is another accessibility trait: .playsSound, that does a similar thing than .startsMediaSession. This one seems more suitable for buttons that have their own sound effects when interacting with them, like it often happens in games.

When interacting with a button with VoiceOver, the accessibility label is repeated to the user. If you are playing some audio, it could be difficult to listen to it properly. To avoid that, you can add the .startsMediaSession accessibility trait.

Images that convey important information should have the .image accessibility trait and provide an alternative text in the accessibility label. "Image" will be added to VoiceOver's utterance and the user will be able to use Image Explorer. Image Explorer is fairly new, introduced just a couple years ago. But if you were appropriately configuring the image trait, users suddenly got this new functionality for free. Isn't that awesome? With VoiceOver on, open Image Explorer by swiping up in an image and double tapping. It lets users find people (with a basic description and positioning in the photo), objects or text in images, using on-device intelligence. It is very cool!

I'll never recommend creating a custom component if there is a native one that does the job. But if you develop a custom tab bar, .tabBar accessibility trait comes to the rescue. Apply to a container view and its buttons will be announced as tabs.

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.