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

The Audio Graphs API has some very nice features aside from being able to consume the graph as audio. You can give it a summary and it will also provide your users with trends, correlations, outliers... and statistics like min and max or the mean.

Creating UIAccessibilityElements, combined with a semanticGroup accessibilityContainerType, can also help you make components as complex as charts accessible. Example from "Bring Accessibility to Charts" WWDC21: https://developer.apple.com/videos/play/wwdc2021/10122/

Sometimes you can create your own accessibility elements from scratch to group elements too. Perhaps because they're not contained in the same superview. You can combine these elements' frames and provide a suitable accessibility label.

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.

Buttons with a title, use it as its default accessibility label. Most cases, that's just perfect. But there's a few times that you might want to tweak it. Maybe the image is part of what the button does, or the text in the title is not very clear.

Sometimes, buttons change meaning, for example when toggled. An example is a play button, tap it and it becomes a pause button. In such case, updating its accessibility label will be clearer than trying to convey the change with traits or values.

Here's a few examples where Apple seems to use the semanticGroup accessibilityContainerType, other than for the tab bar and toolbar, to serve for inspiration on when it might be useful in your own apps. Reminder that this configuration causes for VoiceOver to announce the accessibility label of the container view, before what it would normally announce for an element, only when the focus moves from outside to inside the container.

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

The accessibilityFrame is, by default, the frame of the accessible element. But you can change it. For example, you could expand it, so the interaction area is larger and easier to interact with, and so the user finds less "dead space" in the app.

It is very important to label switches properly and avoid duplication when you find them in table views, like in settings. One way it's usually done, and probably the simplest solution, is by adding the UISwitch in the accessory view of the cell.