1195204 - iOS 9: VoiceOver presents lock image and reader button even when those are not visible

Status: RESOLVED FIXED

(Firefox for iOS :: Browser, defect)

Description

[Boris Dušek]

On iOS 9, VoiceOver presents the reader view button and lock image view to the user even when they are `hidden` (i.e. not visible).

This is due to change in interpretation of `accessibilityElements` by iOS between iOS 8 and iOS 9. On iOS 8, VoiceOver / accessibility runtime filtered out from the accessibilityElements property those UIViews that had hidden = true. On iOS 9, it does not do it, so we should do it manually in the property getter.

Comment 1

[Marco Zehe (:MarcoZ)]

Boris, do you know if this is a final decision made by Apple for iOS 9, or if this might be a glitch in the current betas? The beta cycle is not over yet, and VoiceOver has seen some refinements over the past few iOS 9 builds that make me feel cautious about jumping to conclusions here.

Comment 2

[Boris Dušek]

I do not know whether this is a final decision (and whether this is a decision at all), but after thinking again about accessibilityElements, I concluded that I might have simply relied too much on the current behavior of iOS 8 than on the documentation - I could not find the documentation is not specific about what happens when you return an element from accessibilityElements that is hidden, so I feel it is simply a little bit of a gray area. I figured being explicit in code about the elements desired as children is the safest approach.

One other possibility is that we might not be posting AXLayoutChanged when hidden status changes. But I think this problem was present right after the launch of app, i.e. when the lock image has never been displayed yet (so no way for VoiceOver to have "memorized" it), so I am inclined to think this is not the case.

Maybe a question to Apple's accessibility developer list about what is the intended behavior in such a case (i.e. returning `hidden` `UIView` from `accessibilityElements`) could help.

Comment 3

[Boris Dušek]

(In reply to Boris Dušek from comment #2)
> I could not find the documentation is
> not specific about what happens when you return an element from

"I could not find" shouldn't have been there :-)

Comment 4

[Marco Zehe (:MarcoZ)]

Boris, thanks! I am fine with being explicit about behavior, but I think we should still ask the accessibility dev list whether the changed behavior in iOS 9 is intentional. Are you willing to do that? You are into the code more than I am.

Comment 5

[Boris Dušek]

It starts to get more interesting, I probably jumped to conclusions too quick. I just tried a minimal example to return a mix of hidden and non-hidden UIViews from accessibilityElements and VoiceOver on iOS 9 behaves as I would expect (and not as it behaves in Firefox's location bar) - it presents only the non-hidden elements. So it might be about AXLayoutChanged after all. Will look into it more to be more positive about what is going on (and also about what is *not* going on). Stay tuned :-)

Comment 6

[Marco Zehe (:MarcoZ)]

I can confirm that these buttons are always accessible to VoiceOver while swiping, but not by touch exploration. iPhone 6, latest iOS 9 beta. More irritatingly, the "lock" icon is the first element in the accessible sequence, so it gets VoiceOver focus each time the app is opened and one is on the Home screen of Fennec.

Comment 7

[Boris Dušek]

Attachment: Pull Request

I know this is at the eleventh hour (or maybe rather "past midnight"), but if this could make it into 1.0, it would be great.

And for the record, testing on iOS 9 with Xcode 6.4 sucks :-) - Archive (complete recompile every time) - then Export Ad-Hoc - then Upload app to device in Xcode Devices window... (i.e. Cmd-R does not work - complains about unsupported iOS version)

Comment 8

[Richard Newman [:rnewman]]

We've already cut an RC1, so I'm afraid this'll only go out in 1.0 if we need to cut another release for some reason (either before hitting the big red button or if we're rejected and need to resubmit).

Otherwise it shouldn't be long before our first point release. We're aiming for fairly rapid releases for bug fixes.

Thanks for the painful testing!

Comment 9

[Boris Dušek]

Marco - you can see the commit message for a bit more details, but to cut it short: AXLayoutChanged does not change a thing in this case; I had to manually filter elements returned by accessibilityElements (which btw. I think I started using in the first place to influence order of items when swiping...)

Comment 10

[Boris Dušek]

(In reply to Richard Newman [:rnewman] from comment #8)
> either before hitting the big red button

you mean the one in the suit case to which only the President has the codes? (just kidding ;-)

> Otherwise it shouldn't be long before our first point release. We're aiming
> for fairly rapid releases for bug fixes.

This is great :-) Thanks for all the release info too, good to know.

Comment 11

[Brian Nicholson (:bnicholson)]

Comment on attachment 8651544 [details] [review]
Pull Request

Looks fine to me. Thanks!

Comment 12

[Brian Nicholson (:bnicholson)]

https://github.com/mozilla/firefox-ios/commit/0a1702c2ad2ea2a9cf86b7b0ccff26b775da5698