Re: VO not updating navigation order?
Re: VO not updating navigation order?
- Subject: Re: VO not updating navigation order?
- From: Christopher Hills <email@hidden>
- Date: Thu, 16 Mar 2017 21:23:12 +1000
> If the frames of views are changing like this, VoiceOver needs to be notified with a layout change notification.
Out of curiosity, the same would apply to Switch Control, right?
Thanks,
Christopher
> On 1 Mar 2017, at 2:40 am, Clare Kasemset <email@hidden> wrote:
>
> If the frames of views are changing like this, VoiceOver needs to be notified with a layout change notification. This is not a bug in VoiceOver, but part of the design where VoiceOver is separate from the app process. Generally, if you are sending many layout changes within a short time, VoiceOver only refreshes its elements once, so the spamminess may not be as much of a concern.
>
> Alternatively, do you have any information about the ordering of the views that are off screen, even if you do not know their frames yet? If so, you could try returning all the views from their containing UIScrollView as accessibilityElements in the correct order. If you do this, VoiceOver will ignore their frames when deciding what order to navigate them.
>
> Clare
>
>> On Feb 27, 2017, at 4:23 PM, Charlie Powell <email@hidden> wrote:
>>
>> I've encountered an issue and not clear if it's a bug in VO/UIKit or my app. Essentially, I have a UIScrollView that contains a bunch of child UIViews all of which are accessible. Some of the UIViews are offscreen beyond the UIScrollView's frame, but within its contentSize, etc. Initially, these off-screen UIViews have an incorrect frame because they're *really* far offscreen and my app doesn't doesn't have the necessary state to size them properly until they're closer to being displayed. Eventually they do get updated with the correct frames, but VO doesn't navigate them based on these updated frames.
>>
>> After some investigation, it appears that part of the issue might be related to a previous VO bug we filed (radar 29442252) - because we're unable to correctly size views that are far offscreen, we basically just position them to be after whatever elements we are able to size correctly. We give them a very small height/width, which we've seen cause VO to navigate in an unexpected order (tracked by the aforementioned radar bug). Even if we update the frames before they show up on screen or VO tries to navigate to them, VO will still navigate in the "weird order" that we've observed in the radar bug.
>>
>> I was able to create a sample app where I have 3 accessible views (A, B, and C), 1 of which is visible in the scroll view (view A) and 2 more further down offscreen (views B and C, where B is slightly above C) - all of them have the same horizontal position and size. Initially, VO navigates them in the top-to-bottom order I expect. If I programmatically swap views B and C (by basically setting the frame of one to the other) and navigate by swiping right with VO enabled, then VO actually goes to B before C, even though C is located above B now. Once I navigate there, things seem okay, but this initial behavior is what's causing issues I'm seeing in my app.
>>
>> I found that if I post a UIAccessibilityLayoutChangedNotification, that seems to fix the issue in my app, but I'm concerned about potentially spamming that notification and what the consequences of it would be given the lack of documentation. Naively I could just post it every time the scroll view scrolls or when I update the frames of my views, but that happens quite frequently depending on the user behavior. I suppose another option would be to not even add these problematic offscreen UIViews until I'm able to correctly set their frame, but I'd also like to just understand if there's a VO bug here so that (1) we can try to get it fixed and (2) I can document the workaround in my app to make it clear why this is necessary. Has anyone seen anything like this before, or know of any other things I can try to resolve it?
>>
>> Thanks,
>> Charlie
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
_______________________________________________
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