After exploring a few wrong directions, I think I've figured out what's up. The summary of the problem is that while in VoiceOver mode, we can use the navigational gesture (single finger left or right swipe on screen) to navigate through all the text presented in this view, but arbitrarily tapping or dragging on to individual items (to focus and announce them with via VoiceOver) doesn't work for any of the header items. It seems like some of our custom hit logic (in TalkPageHeaderView and LinkOnlyTextView) is actually preventing VoiceOver from doing its thing. That's why it seems the navigational gesture works fine, but taps/drags do not.

I have a fix prepped that mimics what's done elsewhere in the code base: checks if VoiceOver is enabled and just bails on the custom hit logic if so. But before I move forward with that, I wanted to check if this custom stuff is even necessary.

In my superficial testing with and without the custom point(...) overrides, I'm running into what feels like identical behavior (I'm sure I must be missing something though). Do you recall the initial intention behind the custom hit logic here @Tsevener?

@Dmantena I think (though I haven't tested to be sure) that custom hit logic was purely for users to be able to scroll the collection view underneath through that header, if they aren't tapping on a specific element. The header could take up the entire screen on smaller device sizes / orientations, especially if dynamic type is up, so in that case the user would be stuck without any way to scroll down and see the collection view content, without this custom handling.

Can't reproduce on Wikipedia TestFlight v6.8.1 (1813)

This task can be closed as resolved.

Thanks for help with this issue!

Question:
If I would report something next time can I close it as resolved if I can't reproduce or Developer must do it?
I assume dev should do it.

@Ondreas_novak So glad this one's resolved for you!

If I would report something next time can I close it as resolved if I can't reproduce or Developer must do it?
I assume dev should do it.

Yes, we'll close and mark tasks as resolved. This is so we can be sure any related work is also kept track of and so we can be sure which versions of the app the fixes are included in.

Sounds good to me on 6.8.1 (1815)