Manipulating the VoiceOver cursor programmatically
Manipulating the VoiceOver cursor programmatically
- Subject: Manipulating the VoiceOver cursor programmatically
- From: David Gatwood <email@hidden>
- Date: Thu, 24 Apr 2014 21:01:17 +0000 (GMT)
I'm trying to fix a VoiceOver glitch with an app that uses a table view for an overlay menu. Everything works fine, except:
* When I hide the table view, the VoiceOver cursor remains focused on where the view used to be, and does not follow keyboard focus back to the main view until the user clicks elsewhere in the window.
* If the user does so, the VoiceOver cursor doesn't return to the overlay menu except when explicitly changed via key combinations.
* If the user does so, it then becomes possible to select the overlay menu using VoiceOver key combinations even when it isn't visible.
I was able to make it "work" in 10.9 by sending NSAccessibilityLayoutChangedNotification, but the way it behaves seems fragile (when I add a second overlay, if I send this notification, it makes things worse instead of better, but curiously in this case, posting a NSAccessibilityFocusedUIElementChangedNotification works, whereas it doesn't work for the first overlay element. And of course, the layout changed notification isn't available prior to 10.9 at all.
Is there a better, cleaner way to force the VoiceOver cursor to leave an element that's no longer visible, and to convince VoiceOver to forget about an element, or am I stuck with less-than-ideal behavior pre-10.9?
Also, why don't table views automatically hide themselves from accessibility when you call setHidden with a value of YES? Should I file a bug on that?
David
_______________________________________________
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