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.
You may also find interesting...
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.
Love this feature! Yahoo released the possibility to explore charts with audio, in the finance app, when using screen readers in 2019. You can do now something very similar since iOS 15. https://coolblindtech.com/yahoo-finance-app-makes-charts-accessible-to-blind-and-partially-sighted-users/ You can move your finger in the x-axes, and it will play a sound with a different pitch depending on the data in the y-axes, making it easier to identify trends in the graphs. You need to conform to the AXChart protocol by implementing the accessibilityChartDescriptor property. Documentation: https://developer.apple.com/documentation/accessibility/audio-graphs WWDC21 session: https://developer.apple.com/videos/play/wwdc2021/10122/
While you are at @shelly's "36 Seconds That Changed Everything", I would definitely also check out the Bonus Content. Including the full interview with @marcoarment. "Awareness is the biggest problem here." https://www.36seconds.org/behind-the-scenes/ "Cause iOS 7 was so inaccessible in so many ways (...) it started getting under developers’ radars this section of settings, called accessibility, that changes the way my app looks or works and I need to make sure that it doesn’t break under those settings.” "There’s so much variation out there. We no longer have just one size phone, we no longer have just one font size. It is easier for us as developers not to fall into bad assumptions of how I see it is how everyone is going to see it.” "The good thing about VoiceOver is that the accessibility framework is pretty well built-in the standard controls. For a given app you can fix any VoiceOver problems it has in one day or less. Even if it is a complex app. Even if it has a lot of custom controls." "What developers now do, if they care, is they treat that (accessibility issues) as if it was any other design flaw. If any other screen in your app broke visually or functionally you’d consider that a bug and you would try to fix it in the next update.” "I think the more that we can do as a developer community to talk about these features even existing, and these problems existing, and to tell people how easy it is to fix. That is the best any of us can do to help. Awareness is the biggest problem here."
