Quick and easy accessibility changes you can make today
Making your app accessible might not make much difference to you personally, but it can and will make a world of difference to many users around the world.
I’ve been attending various talks on iOS accessibility recently. One of them was by Hung Truong from Lyft, and he was asked a question: “I’m trying to convince my boss we should add accessibility – do you have any statistics you can share?”
I loved Hung’s response: “adding accessibility isn’t about making more money, although that might happen. Adding accessibility is about your company culture, and what you actually value.”
So, I’m not going to try to convince you to add VoiceOver – hopefully you’ve already seen just how important it is. Instead, I want to give you a 10-minute check up that you can run on your current projects to get an idea of how accessible they are, along with some advice on how to improve.
SPONSORED Let’s face it, SwiftUI previews are limited, slow, and painful. Judo takes a different approach to building visually—think Interface Builder for SwiftUI. Build your interface in a completely visual canvas, then drag and drop into your Xcode project and wire up button clicks to custom code. Download the Mac App and start your free trial today!
Sponsor Hacking with Swift and reach the world's largest Swift community!
Let’s start with VoiceOver. Although it’s only one of many accessibility features inside iOS, VoiceOver is easily one of the most important because it helps such a wide range of users. Even better, it acts as a fast and easy way to audit your accessibility because you’ll find you can select things that ought to be unselectable, and you’ll often even hear jumbled text as VoiceOver tries to make sense of your UI.
Start by enabling VoiceOver in the Settings app, under General > Accessibility. If you haven’t used VoiceOver before, you can scroll around using three-finger swipes, select elements by tapping on them, and activate controls by double tapping.
accessibilityLabel
property.accessibilityHint
property.accessibilityTraits
property (exposed as a series of checkboxes in IB) lets you describe what functionality your components do – if they are they buttons, links, or images, and so on.UIAccessibilityTraitButton
will have VoiceOver say “button” after your label, telling folks it will trigger an action. You might find this useful for your table view cells if they trigger actions: cell.accessibilityTraits |= UIAccessibilityTraitButton
does just that.cell.isAccessibilityElement = false
then cell.contentView.subviews.forEach { $0.isAccessibilityElement = true }
. Be warned, though: splitting cells up in this way can cause a lot more screen reading and really slow users down.
Next let’s look at how you size things:
preferredFont(forTextStyle:)
method of UIFont
when choosing your fonts. For example, using .headline
will give you a larger, bolder font.adjustsFontForCategorySizeCategory
property to true for any labels that use Dynamic Type. This may already be enabled for you, but there’s no harm being sure.UIFontMetrics
to scale it up. You can read more here, but really it’s just a matter of creating a font metrics object using something like UIFontMetrics(forTextStyle: .headline)
then running fontMetrics.scaledFont(for: font)
to get back a scaled UIFont
.
Moving on, let’s look at how you arrange things:
accessibilityViewIsModal
property to true
.UITabBarController
and UINavigationController
work great with accessibility out of the box – the system does a great job of helping users navigate through controls in a natural way. So, if for some reason you’re using a hamburger menu or some other custom hierarchy, consider revising that.accessibilityPerformEscape()
method and dismiss itself there.accessibilityPerformMagicTap()
in your view controller, then make it do whatever action you think best.UIAccessibilityIsReduceTransparencyEnabled()
or UIAccessibilityIsReduceMotionEnabled()
respectively – both return true or false depending on the setting, allowing you to take appropriate action.
Finally, some quick tips:
UILabel
, UIButton
, UISlider
and such are all highly accessible out of the box – they work like users are used to from other iOS apps.UIView
yourself it’s harder. Make sure you set isAccessibilityElement
to true if you’ve made it accessible, and consider setting its accessibilityValue
property to something meaningful that VoiceOver can read. This might be something unique, or might be a summary of values from inside it.UIAccessibilityIsVoiceOverRunning()
, and show different UI as needed. For example, if you write an email app that pops up a small “Message sent” label then hides it after a couple of seconds, that will work badly with VoiceOver.If you’d like to learn more about accessibility (and I hope you do!), I can recommend two excellent talks. The first is from Sommer Panage and is called Accessibility for Users, Designers, and Developers, and the second is from Sally Shepard and is called Beyond VoiceOver – both cover a variety of other ways to help identify and resolve accessibility in your apps.
SPONSORED Let’s face it, SwiftUI previews are limited, slow, and painful. Judo takes a different approach to building visually—think Interface Builder for SwiftUI. Build your interface in a completely visual canvas, then drag and drop into your Xcode project and wire up button clicks to custom code. Download the Mac App and start your free trial today!
Sponsor Hacking with Swift and reach the world's largest Swift community!
Link copied to your pasteboard.