Mobile A11y

SwiftUI previews offer a fast, practical way to see the output of our view code. But did you know you can also use them to test accessibility-related UI changes including Dynamic Type, localisation, and system accessibility settings, all without needing a physical device.

"SwiftUI is accessible by default" is one of the most repeated misconceptions in iOS development. Here’s why that’s wrong and what you actually need to watch out for.

For iOS, Accessibility values are one of the building blocks of how Accessibility works on the platform, along with traits, labels, hints, and showing/hiding elements. If you’re familiar with WCAG or web accessibility, accessibility values are the value part of WCAG 4.1.2: Name, Role, Value. Values # Not every element in your view will have a value - in fact, most won’t. Any element that ‘contains’ some data, data that is not included in the element’s label requires an accessibility value to be set. If you’re using standard controls provided by Apple, these values will be set for you. But if you make something custom you must add a value where necessary, and if you’re extending a standard control, testing with VoiceOver is essential.

Accessibility traits on iOS is the system by which assistive technologies know how to present your interface to your users. The exact experience will vary between assistive technologies, in some cases they may change the intonation of what VoiceOver reads, or add additional options for navigation, sometimes they will disable that assistive technology from accessing the element, or change how the assistive tech functions. They are the ‘Role’ part of the fundamental rule of making something accessible to screen readers - WCAG’s 4.1.2: Name, Role, Value.

When testing your app with VoiceOver or Switch Control, a common test is to ensure you can reach every interactive element on screen. If these assistive technologies can’t focus all of your buttons how will your customers be able to interact fully with your app? Except there are times when hiding buttons from your assistive technology users is the better choice. Consider an app with a table view that has many repeating interactive elements - this could be a social media app where ’like, share, reply’ etc is repeated for each post. Or perhaps an e-commerce app with ‘wishlist, buy now, add to basket’ are repeated for each item. Visually these buttons won’t interrupt your users skimming the list of content, but for VoiceOver or Switch Control users, they will have to visit each one for every item on the screen. This is going to make navigating your app long and tedious, an means your users are more likely to drop out.