Re: Manipulating the VoiceOver cursor programmatically
Re: Manipulating the VoiceOver cursor programmatically
- Subject: Re: Manipulating the VoiceOver cursor programmatically
- From: David Gatwood <email@hidden>
- Date: Fri, 25 Apr 2014 02:51:16 +0000 (GMT)
On Apr 24, 2014, at 03:07 PM, Josh Scotland <email@hidden> wrote:
On Apr 24, 2014, at 2:01 PM, David Gatwood <
email@hidden> wrote:
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?
Depending on the situation, you might be stuck using API introduced in 10.9. NSAccessibilityLayoutChangedNotification gives AX clients (e.g. VoiceOver) a way to respond and update cursor context. Posting it after a view disappears is proper usage.
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?
Are you seeing this behavior even after posting NSAccessibilityLayoutChangedNotification? If yes, then file a bug about VoiceOver’s cursor. If no, file a bug that setHidden: should handle the notification for you.
What I'm seeing is:
1. When I hide the first overlay element (the menu), if I send NSAccessibilityLayoutChangedNotification, it does the right thing and returns focus to the main content view.
2. When I hide the second overlay element (an about box opened from that menu, located beside the menu), if I send NSAccessibilityLayoutChangedNotification after I close the about box, it incorrectly sends focus back to the main content view, which is undesirable, rather than back to the previously focused view. If I don't do anything, the focus returns to the menu view.
So sending the notification is a mixed bag that helps in some cases, but hurts in others, because the cursor always returns to the main content view whenever I send that notification. I've even tried overriding the accessibilityFocusedUIElement method of the content view so that it always returns the view that should be focused. Although the method does get called, the view I return doesn't seem to have any actual effect on the behavior of the cursor.
I'm also sporadically seeing VoiceOver interfere with arrow navigation in the table view. Turning VoiceOver off and back on again fixes the problem.
In an ideal world, explicitly setting the firstResponder for a view would automatically result in VoiceOver's cursor moving to match. Perhaps that's the bug I should file, rather than filing bugs about all the bizarre edge cases caused by trying to work around the lack of that default behavior.
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