Exploring VoiceOver Accessibility for UITableView

Question

Created Mar ’25

Replies 3

Boosts 0

Participants 2

I’m currently exploring VoiceOver accessibility in iOS and looking for the best way to reduce the number of swipes required to navigate a UITableView. I’ve come across a couple of potential solutions but am unsure which is preferred.

Solution 1: Grouping Subviews in Each Cell

Combine all subviews inside a UITableViewCell into a single accessibility element.
Provide a concise and meaningful accessibilityLabel.
Use custom actions (UIAccessibilityCustomAction) or accessibilityActivationPoint to handle interactions on specific elements within the cell.

Solution 2: Using UIAccessibilityContainerDataTableCell & UIAccessibilityContainerDataTable

Implement UIAccessibilityContainerDataTable for structured table navigation.
Make each cell conform to UIAccessibilityContainerDataTableCell, defining its row and column positions.
However, I’m finding this approach a bit complex, and I need guidance on properly implementing these protocols.
Additionally, in my case, VoiceOver is not navigating to Section 2—I’m not sure why.

Questions:

Which of these approaches is generally preferred for better VoiceOver navigation?
How do I properly implement UIAccessibilityContainerDataTable so that all sections and rows are navigable?
Any best practices or alternative recommendations?

Would really appreciate any insights or guidance!

Answered by Frameworks Engineer in 827679022

Hey! Great question. My recommendation is Solution 1 you've outlined above.

If you have a table view cell with multiple, small, discrete elements, you should absolutely find ways to group them semantically.

It may mean the entire cell is 1 element, or a few like 2 or 3. This will not only help reduce the amount of swiping required to navigate your app, it will also make it easier for someone to understand your UI because elements will be grouped by information.

Check out this developer article. Mainly, the section "Group and declutter accessibility elements", https://developer.apple.com/news/?id=v56qu1b3

If you have specific questions about grouping the elements in your app, feel free to discuss here!

Boost

Answer 1

Frameworks Engineer OP

Apple

Mar ’25

Accepted Answer

Hey! Great question. My recommendation is Solution 1 you've outlined above.

If you have a table view cell with multiple, small, discrete elements, you should absolutely find ways to group them semantically.

It may mean the entire cell is 1 element, or a few like 2 or 3. This will not only help reduce the amount of swiping required to navigate your app, it will also make it easier for someone to understand your UI because elements will be grouped by information.

Check out this developer article. Mainly, the section "Group and declutter accessibility elements", https://developer.apple.com/news/?id=v56qu1b3

If you have specific questions about grouping the elements in your app, feel free to discuss here!

1

Answer 2

Praveenraj4256 OP

Mar ’25

@Frameworks Engineer

To minimize swipes, I wrapped all elements into a single accessibility element in UITableViewCell and used UIAccessibilityCustomAction to trigger the button’s action.However, the issue arises when this button interaction needs to display a menu. Since the menu cannot be triggered programmatically, how can I achieve this ?
Some articles mention that wrapping all visible elements into a single accessibility element is not a good practice. This is because VoiceOver users are not always completely blind, many have partial vision and may try to focus on specific elements individually. If everything is grouped into one element, it can make navigation feel restrictive.I’d love to hear your thoughts on this ,what’s the best approach to balance accessibility and usability in such cases?

0

Answer 3

Frameworks Engineer OP

Apple

Mar ’25

Inside your custom action block, are you able to call the accessibilityActivate method on the button which has the sheet action? Try it out and see if that triggers an activation. Each accessibility element has this method that may be overridden, but you may be able to call it directly in cases like this. https://developer.apple.com/documentation/objectivec/nsobject/1615165-accessibilityactivate
I think that word of caution is just to provide context to you as the developer. When you group elements, think about whether it makes sense, and don't overdo it. If you have specifics about your UI that you can share here, please feel free. You can also look around in first party apps like Health, Shortcuts, etc, and see how UI elements are grouped in the context of accessibility for some inspiration

0