iOS VoiceOver/rotor: header navigation not going back to navigation bar

Question

In the app I'm working on, there is one UITableView with section headers. The tableView is in a UIViewController that is embedded in a UINavigationController. With VoiceOver on, and the rotor set to headings, I want to be able to navigate from one header to the next, back and forth, using the swipe up/down feature.

I have validated that the navigation bar title and the tableView section headers all have the accessibility trait of .headers.

What is currently working:

• swipe down, from the navigation bar's title to the first tableView section headers
• swipe up and down between sections to navigate between them.

What is not working:

• swipe up from the first section header to the navigation bar title.

There is another view controller in the app where it's working, so I know it's possible, but I can't figure out why the behaviours differ.

I tried:

• setting different accessibility properties to the navigationBar/item
• comparing the working and non-working view controllers with the Debug View Hierarchy (as far as I can tell, they have the same hierarchy and same accessibility attributes).
• Because of this question, I also looked at how the viewControllers are presented, and it's the same thing.

Is there an aspect of it I'm overlooking? What elements/attributes have an impact on the rotor heading navigation?

Answer 1

It looks like it's a UIKit bug. The difference between working and non-working view controllers is the presence or not of a first section without a header. The image below explains it better. In the picture, the arrows represent working navigation (how VoiceOver focus moves from one headings to the next with swipe up/down gestures).

Upon further investigation, I saw that in the Settings app, the Mail section has the same issue. (Screenshot as a reference). If the VoiceOver focus is on "Allow mail to access", swipe up does not lead to the focus on "Mail" title in the navigation bar.

As far as I can tell, SwiftUI does not have the issue, so we'll see about rewriting the view with SwiftUI.