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 04:28:09 +0000 (GMT)
On Apr 24, 2014, at 08:47 PM, Josh Scotland <email@hidden> wrote:
Hey David,
On Apr 24, 2014, at 7:51 PM, David Gatwood <email@hidden > wrote:
> 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.
Right, the NSAccessibilityLayoutChangedNotification just tells an accessibility client that the view’s layout has changed — it does not provide any more information as to what the client should do after the view’s layout has changed. VoiceOver only refreshes its cursor context when it receives the notification, which is not desirable in this case.
> 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.
I agree with your general point. Let me ask for your opinion of a possible solution below. First, I want to point out that syncing the VoiceOver cursor to the first responder (the control that typically has keyboard focus) is not always viable. This is the case for two important reasons:
1. VoiceOver needs to be able to traverse all kinds of elements, even those that are not allowed to become first responder.
2. Sometimes it is useful to turn off VoiceOver cursor follows keyboard focus (see VoiceOver Utility - > Navigation options) and VoiceOver has to respect that preference.
Makes sense.
Now for the possible solution. iOS has API that lets developers programmatically manipulate where the VoiceOver cursor should go. Would it help the issue you are seeing here if there was a corollary API for OS X? Instead of posting a generic notification, you could tell accessibility clients that a particular UI element should now gain focus.
I'm pretty sure that an OS X equivalent of the iOS API would work perfectly, yes. :-)
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