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.

Very often we need to show a UISwitch preceded with a UILabel that explains what it does. The text in the label is basically the accessibility label for the switch. Ideally we want for both components to be grouped behave as a UISwitch. It makes much easier to understand what the switch does, compared to having two separate accessible components. There is a number of ways you can do that. One of them is to use a container view and proxy the switch accessibility attributes.

It is possible to change the traversing order of accessibility elements by configuring the accessibilityElements array. You should try to avoid it, but one good reason for doing it is if the default order is illogical because of the visual layout.

By its name, I misunderstood what shouldGroupAccessibilityChildren does the first time I saw it. It can be used for VoiceOver to traverse all items in a view before moving to the next one, instead of grouping as in combining those elements. VoiceOver traverses elements in the natural reading order, from left to right, top to bottom, in left-to-right languages. Sometimes data is displayed in columns, so that order might not be the most logical one. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/shouldgroupaccessibilitychildren

This is a small trick I use to compose complex accessibility labels/values when, for a UI component, some elements might not be in all its instances. An array of optional Strings, compact map, and join all elements by a separator, like a comma.

If both screenChanged and layoutChanged notifications signal changes in the UI and allow you to move VoiceOver's focus somewhere else, what's the difference? To the user, screen changed plays a sound indicating them they got moved to a new screen.

It can help to alert the user of something that happened, in a part of the screen that is not currently on focus, and that is not important enough to disrupt the user by moving VoiceOver’s focus to a different place. It can be useful to announce certain messages like errors or long running tasks that have finished (i.e. a download that finished) or with custom notifications and snack bars.

Sometimes, you change your app's UI to offer more options as a result of a user's action. And in such cases, it might be a good idea to move VoiceOver's focus to these new options. We can do that by sending a layout changed notification.

Even when setting a view as modal for accessibility, you may notice that VoiceOver's focus stays in the same place, instead of moving to the presented view. You can post a screen changed notification and pass the view that should get the focus.

When presenting a UI component that overlays the existing UI, you may have found that VoiceOver starts to randomly jump between the overlaid UI and the elements underneath. To avoid that, you can set its accessibilityViewIsModal to true. When setting the accessibilityViewIsModal to true for a view, VoiceOver will ignore its sibling views, treating it as if it was a modal. Useful when presenting custom popups, popovers, modals, action sheets, etc. https://developer.apple.com/documentation/objectivec/nsobject-swift.class/accessibilityviewismodal