If a view has isAccessibilityElement to true, assistive tech won't look for any of its subviews. That means that if there are any buttons inside, they won't be accessible. You can add custom actions to that element though.

Calendar of Advent of iOS Accessibility. Day 8. Inaccessible buttons within accessible views. Example of the Mastodon app. If we make the table view cell representing a post an accessible element so it is easier to navigate, the subviews, including the buttons, won't be accessible anymore. So how can a VoiceOver, Keyboard, Voice Control, or Switch Control user interact with them? Custom actions to the rescue. In SwiftUI there is a new modifier, since iOS 16, called accessibilityActions. Before, you had to add the actions one by one. In UIKit, there is an accessibilityCustomActions property, which is an array of UIAccessibilityCustomAction.

You may also find interesting...

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/

You can add your Accessibility Shortcuts to Control Centre too. One more quick access point and one more reminder to get you testing often and quickly. How to enable Accessibility shortcuts: https://x.com/dadederk/status/1583519154165800960?s=61&t=_fK9Muzu2MyFEeJLVQZcJg

An alternative layout for large font sizes can be provided with Auto Layout by having three sets of constraints (common, default constraints, and alternative constraints) and activate/deactivate them depending on the content size category.

Created in Swift with Ignite.

Supporting Swift for Swifts