Tips and tricks to build accessible iOS apps

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.

If you need to send announcement notifications that can step into each other, they will by default, interrupt ongoing announcements. But you can pass attributed strings as parameters too, letting you specify announcements to be queued.

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

What is the difference between isAccessibilityElement and accessibilityElementsHidden? The first one makes the view not accessible, but its subviews can still be accessible. The second one hides the view and all its subviews from assistive tech.

If you need for a view (and all its subviews) not to be focusable by assistive tech like VoiceOver, you can set its accessibilityElementsHidden property to true. This isn't needed very often, but it can be useful for certain custom experiences.

The Accessibility APIs are generic and flexible. They're not just for VoiceOver. If you implement them right, you can do it once and it will very likely work great for VoiceOver, Voice Control, Switch Control, Full Keyboard Access, and more. That's why, to start with, we tend to focus on VoiceOver, the same way you may focus on keyboard navigation for the web. A great VoiceOver experience will get you most of the way to a good experience with the other assistive technologies. We've seen one example with Custom Actions. One implementation works for: VoiceOver: https://x.com/dadederk/status/1550099327053451266 Switch Control: https://x.com/dadederk/status/1551236244088279040 Full Keyboard Access: https://x.com/dadederk/status/1551874732504629249 And Voice Control: https://x.com/dadederk/status/1552253520182640645 Of course that doesn't mean you don't have to test and check how the experience is with the other technologies. But before feeling overwhelmed, or for small teams, making sure your app works for VoiceOver is a great start.

Custom actions work with VoiceOver, Switch Control and Full Keyboard Access. They also do for Voice Control. You can say "Show actions for <item name/number>", and an action sheet with all options, numbered, will be presented to the user. For some use-cases, Voice Control users might not feel it is a big win. Navigation is not as big of an issue, and interacting with custom actions might be a bit trickier than with "exposed" buttons. But lots of times seems a fair compromise.

Custom actions work well with VoiceOver and Switch Control. It is also a way of speeding up navigation, and grouping all actions available for an item in a single place, with Full Keyboard Access. Focus an item and use the shortcut Tab (⇥) + Z.

Since iOS 14, UIAccessibilityCustomAction has an initialiser that accepts an image, as well as a name and action handler. Configuring one will make your custom actions easier to spot in the Switch Control menu. https://developer.apple.com/documentation/uikit/uiaccessibilitycustomaction/init(name:image:actionhandler:)

Custom actions work as great on Switch Control as they do in VoiceOver. It makes navigation much, much, faster and you’ll be able to find all those custom actions in the Switch Control menu.

Potential benefits from grouping logical pieces of information and moving buttons to custom actions: reduce redundancy (by removing repetitive controls) and reduce cognitive load (by making easier to know what item will be affected by each action)