SwiftUI Accessibility
Accessibility is important. We can take that as a given. But as iOS devs we’re not always sure how to make the most of the accessibility tools that Apple have provided us.
We’re lucky as iOS developers that we work on such a forward-thinking accessibility platform. Many people consider Apple’s focus on accessibility for iOS as the driver for other technology vendors to include accessibility features as standard. To the point that we now consider accessibility an expected part of any digital platform. This was not the case before 2009.
In Shelly Brisbin’s fantastic audio documentary 36 Seconds that Changed Everything: How the iPhone Learned To Talk she outlines what it meant to blind and partially sighted people to be locked out of the early iPhones.
I was sad because I felt, ‘here’s another time we’re going to be left out’. Eventually, someone’s going to make a special blindness-specific iDevice. It’ll be three versions old. It’ll cost four times as much, and we’ll just keep buying it, cuz it’s the only option that we have.
For the first time in 20 years, Apple had built a product I couldn’t use. I’m fairly sure I cried about that.
Being locked out is the reality for many of your customers if you don’t consider accessibility right from the start. Accessibility in UIKit is indeed world-class, but it will only ever be an add-on.
This time around, with SwiftUI, Apple has taken the chance to re-think how some of their accessibility tools work for developers, and they’ve baked in accessibility right from the very beginning. Apple’s accessibility teams have been an integral part of some of the decisions that have shaped SwiftUI. You can see this throughout your SwiftUI code. Like the way images are now accessible by default. How controls are now all linked to text names. And how dynamic type is now the default. This is exactly why I believe this guide to SwiftUI accessibility is important right now. Let’s follow Apple’s lead and make accessibility a first-class citizen in our apps.
The biggest change, that will make the most impact for your users requires no work from you at all aside from adopting SwiftUI. That is down to how SwiftUI generates its accessibility tree or accessible user interface. Meaning your assistive technology users will always get the experience you intended.
Tweaking your accessible experience is still possible in areas where your UI doesn’t quite work for assistive technology users. Accessibility attributes and traits can still be set on every view in a way that should feel familiar from UIKit. But SwiftUI’s improvements for setting the accessibility sort priority and creating semantic views make these techniques so simple there’s really no reason not to use them.
Sometimes we make the mistake of thinking about accessibility as something for other people. But accessibility is all about customisation. We all like to make changes to our device to make it work better for us, like every developer’s favourite: dark mode. So it’s also essential to listen to your customer’s preferences for accessibility settings and decide how your app should respond. This will give all your customers the best possible experience.
I can’t wait to start using your accessible SwiftUI apps. If you’re unsure of the best way to improve accessibility for your app, feel free to reach out.
Thanks for reading. This story is part of a series on SwiftUI Accessibility. Check out my other guides in this series:
SwiftUI Accessibility SwiftUI Accessibility: Named Controls SwiftUI Accessibility: Images SwiftUI Accessibility: Dynamic Type SwiftUI Accessibility: Accessible User Interface SwiftUI Accessibility: Sort Priority SwiftUI Accessibility: Attributes SwiftUI Accessibility: Traits SwiftUI Accessibility: User Settings SwiftUI Accessibility: Semantic Views