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...

Apple asks us to consider the combine behavior, before using ignore, for .accessibilityElement(children: ). And for good reason, if combine works, and later on you decide to change the UI, the accessibility attributes will be updated for you.

A common example where you need to manually configure the button accessibility trait is for some table/collection view cells. These tend to be “buttons” that perform an action, like playing music, or bring the user to a different screen.

Color contrast between text and background is very important for perceivability. As colors come closer to each other, they’re more difficult to distinguish. Notice that colors that work well with big font sizes may not for smaller text.

Created in Swift with Ignite.

Supporting Swift for Swifts