Tips and tricks to build accessible iOS apps

You should convey important information in multiple modes, not just color. If you are still required to do so, at the very least you should complement that info with other modes, like symbols, if the user requested differentiation without color.

All the accessibility capabilities you can check for, have counterpart notification names you can observe in case the user changes its preferences while using your app. https://x.com/dadederk/status/1577435144129892352

There are a ton of customisation options in the accessibility settings in iOS. When doing things the Apple way, this options should, in most cases, just work for you. If not, you can find flags to check for all these options in UIAccessibility.

You can add an observer to listen for changes in the content size category, in case it is more convenient than overriding traitCollectionDidChange(_:).

If you want to keep yourself up to date with what’s going on, or what has been published lately, on how to develop more accessible mobile apps, make sure you subscribe to Accessible Mobile Apps Weekly by @RobinKanatzar from @accessible_apps.

Consider setting a higher number of lines in your labels for large content size categories. Even to 0 (it means unlimited). That way you ensure the user will have access to the same amount of content regardless of the text size configured.

If you use SwiftLint in your SwiftUI project, there is a rule, by @rerycole34, for making sure that your images have either an accessibility label or are hidden for assistive tech because they might be decorative. Rule: https://realm.github.io/SwiftLint/accessibility_label_for_image.html

You can pass the .escape AccessibilityActionKind to the accessibilityAction(_:_:) modifier, to implement the perform escape gesture in SwiftUI. A reminder of how perform escape works: https://x.com/dadederk/status/1549066893377830913?s=20&t=Aog7ojR4E4eG4M3hd-cn3w

@NSSpain has a great history of having amazing accessibility talks in their schedule! “Accessibility in the Real World”, by @Sommer: https://vimeo.com/235317172 “How to build an app for everyone”, by @NovallSwift: https://vimeo.com/362163043 The super fun "Choose your own SwiftUI adventure - 3 Accessibility", by @twostraws and @PinkerStraws: https://vimeo.com/481768105 And, of course, this year's great "Bas: My Accessibility Story", by @basthomas: https://vimeo.com/751176747

A very special one for me today! The recording of my #NSSpainX talk is now available! If you've been following , you'll find lots of the slides familiar. I would love to hear what you think about it! https://x.com/NSSpain/status/1574801556775620614?s=20&t=Aog7ojR4E4eG4M3hd-cn3w

Looking at how to implement the magic tap in SwiftUI? There is an accessibilityAction(_:_:) with an action kind parameter, you can pass .magicTap, and a closure to handle that action. A reminder of what the magic tap is: https://x.com/dadederk/status/1548791545800888322?s=20&t=ZakzzXNfLk0-2kpYqD5v3A

For other UI elements that could also benefit from being scaled when using Dynamic Type, you can use UIFontMetrics's scaledValue(for:). Some good examples are progress bar components, which tend to be quite slim. https://developer.apple.com/documentation/uikit/uifontmetrics/scaledvalue(for:)

If you have any web views in your app (Terms and Conditions and Privacy Policy, I'm looking at you), you can also support Dynamic Type for them. You can set an Apple system font with the same styles available for native development in your CSS.

When configuring a largeContentImage or adjustsImageSizeForAccessibilityContentSizeCategory, it is important to use a pdf asset and preserve the vector data so the icons are crisp at any size.

When implementing the large content viewer, UIKit components will usually have a large content title and image configured for you. But if you are developing a custom component, or you want to add info to a native component, you can do so.