iOS: A11y only disable during app resigning to background when voice over on #32820
Conversation
| @@ -826,7 +826,9 @@ - (void)applicationBecameActive:(NSNotification*)notification { | |||
|
|
|||
| - (void)applicationWillResignActive:(NSNotification*)notification { | |||
| TRACE_EVENT0("flutter", "applicationWillResignActive"); | |||
| self.view.accessibilityElementsHidden = YES; | |||
| if ([FlutterViewController isUIAccessibilityIsVoiceOverRunning]) { | |||
| self.view.accessibilityElementsHidden = YES; | |||
There was a problem hiding this comment.
What about when someone is using a physical switch device or voice input? Does this break things in those cases?
There was a problem hiding this comment.
this looks like it will break if voice control is turned on, unfortunately there isn't an API to detect whether voice control is on last time i checked
There was a problem hiding this comment.
Could we flip the sense of this and allow tests to pass some parameter/set some environment variable to override this behavior?
There was a problem hiding this comment.
Do we need self.view.accessibilityElementsHidden = YES; if voice input is on? I remember self.view.accessibilityElementsHidden = YES; is to fix the exact issue where the voice over is on and the focus is jumped to flutter view.
There was a problem hiding this comment.
So in the current code, we always hide accessibility elements. Now, with the change in this PR, we only hide the elements when voice over is turned on. This would actually be an improvement for voice input (by not hiding a11y elements when voice over is off)
I couldn't find any concrete example for voice input to test tho.
There was a problem hiding this comment.
I think the concern is whether "showing" the a11y elements when a dialog is up will confuse voice input.
There was a problem hiding this comment.
I think it's probably fine, but it would be good to test an app that has voice input turned on while it shows a permissions dialog, and make sure you can use voice input there the same as you would be able to use it in a regular native iOS app in that situation. I'm not familiar enough with voice input to know how to test this myself.
If a manual test shows that it works ok, that's probably the best we can do. If not then we need to figure out how to change this only for tests.
There was a problem hiding this comment.
Tested with voice control, it seems working fine. See below video:
https://drive.google.com/file/d/14DErLf2G_f_cfd6miU-DyJIhzMBWIW0L/view?usp=sharing
cyanglaz
added
the
waiting for tree to go green
This PR as another condition to when the accessibility is disabled. The new condition is when the voice over is on.
Disabling accessibility when app resigning to the background breaks XCUITests that contains a system popup. Because XCUITests uses accessibility but doesn't require the voice over feature to be on, we can keep the accessibility enabled while voice over is off so the tests would work again.
Fixes: flutter/flutter#93504
Pre-launch Checklist
writing and running engine tests.
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.