Hello Victor,
one more tip I stumbled upon yesterday (btw. we call the phenomenon you described a VoiceOver black hole):
4. Make sure whenever views appear/disappear on the screen, you post UIAccessibilityLayoutChangedNotification and/or UIAccessibilityScreenChangedNotification. An example I discovered yesterday is that when WKWebView finishes loading a webpage (as determined by [WKNavigationDelegate webView:didFinishNavigation:] delegate method), just posting UIAccessibilityScreenChangedNotification will make VoiceOver cursor land on the correct initial element in web page (e.g. the first one, or the focused one), but sometimes VoiceOver cursor can be stuck on this initial element (e.g. on a Wikipedia article, it landed and got stuck on the “Open main menu" link - the link became the VoiceOver black hole, swiping left/right made the sound that there is nothing more). If then followed by UIAccessibilityLayoutChangedNotification, the “black hole” in this case vanishes and it is possible to move to different elements by swiping left/right. In this case, both notifications specified nil as their arguments, i.e. I left it to VoiceOver to figure out where (and if) to move the cursor.
Of course, based on the specific situation, you might want to (or it is sufficient to) send just one of these notifications (instead of both) and/or specify the location to move to in the notification parameter (instead of specifying nil).
I hope this helps in some cases.
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden