When making charts accessible, sometimes you may have just too many data points for the user to have to go one by one through all of them. In those cases, you can create accessibility elements that represent meaningful chunks of the graph.

Apple maps app showing a bicycle route to the BBC Broadcasting House. There is a graph showing elevation. there are many data points for the 6.1 mile ride. Apple groups a few of these data points so it is easier to consume the data with VoiceOver. In the example, a portion of the chart is selected and VoiceOver announces: From 3.5 miles to 4.2 miles, climb 23 feet, descend 43 feet.

You may also find interesting...

What is the difference between isAccessibilityElement and accessibilityElementsHidden? The first one makes the view not accessible, but its subviews can still be accessible. The second one hides the view and all its subviews from assistive tech.

Sometimes you want to prioritise ease of navigation, and that's when configuring isAccessibilityElement to true on a container view makes sense. This is especially true in table/collection views and with complex cells with lots of elements. Take the example from a tweet (from Day 62's tweet). If the tweet has 9 accessible elements, you'd need 9 swipes to the right to go to the next tweet in the list. But ideally, I single swipe should be enough. https://x.com/dadederk/status/1549417799746994177 On the other hand, for the detail screen for a single tweet, you want to optimise for ease of access to each one of the elements, instead of navigation. In that case it would be better for the tweet view not to be an accessibility element.

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.

Created in Swift with Ignite.

Supporting Swift for Swifts