Grouping elements when it makes sense can make a huge impact on easing navigation with some assistive technologies like VoiceOver, Switch Control, or Full Keyboard Access. It also helps on reducing redundancy.

Grouping elements when it makes sense can make a huge impact on easing navigation with some assistive technologies like VoiceOver, Switch Control, or Full Keyboard Access. It also helps on reducing redundancy.


Custom actions work with VoiceOver, Switch Control and Full Keyboard Access. They also do for Voice Control. You can say "Show actions for <item name/number>", and an action sheet with all options, numbered, will be presented to the user. For some use-cases, Voice Control users might not feel it is a big win. Navigation is not as big of an issue, and interacting with custom actions might be a bit trickier than with "exposed" buttons. But lots of times seems a fair compromise.
Do you know when a UI element is greyed out to show that it is disabled? Yes, there is an accessibility trait for that too: .notEnabled. VoiceOver will say “dimmed” after its accessibility label and Voice Control and Switch Control will skip it.
If you want to know everything about how to "Tailor the VoiceOver experience in your data-rich apps" with the Accessibility Custom Content API, there is a WWDC21 session. https://developer.apple.com/videos/play/wwdc2021/10121/ When implementing accessibilityCustomContent, for any supplementary information, it returns an array that VoiceOver will announce in that given order. The value of the AXCustomContent first, then the label. Users can configure in VoiceOver's verbosity settings if it should say that there's more content available, or play a sound hinting that there is, or simply do nothing. So it should really be optional content as users might miss it.
Content © Daniel Devesa Derksen-Staats on Accessibility up to 11! is licensed under CC BY 4.0. License details