Tips and tricks to build accessible iOS apps

Love this feature! Yahoo released the possibility to explore charts with audio, in the finance app, when using screen readers in 2019. You can do now something very similar since iOS 15. https://coolblindtech.com/yahoo-finance-app-makes-charts-accessible-to-blind-and-partially-sighted-users/ You can move your finger in the x-axes, and it will play a sound with a different pitch depending on the data in the y-axes, making it easier to identify trends in the graphs. You need to conform to the AXChart protocol by implementing the accessibilityChartDescriptor property. Documentation: https://developer.apple.com/documentation/accessibility/audio-graphs WWDC21 session: https://developer.apple.com/videos/play/wwdc2021/10122/

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 create your own accessibility elements from scratch. One use-case for doing that is when you do some custom drawing instead of building your UI using or relying on UIKit components. A circular progress bar, could be an example.

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.

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