Talkback doesn't always see platform view contents in Hybrid Composition mode

[stuartmorgan]

During investigation of #101887 I'm seeing that platform view accessibility seems to be broken in at least some cases in Hybrid Composition.

Example steps to reproduce:

• Run the example app from webview_flutter, making sure it's in HC mode (currently that's true by default because of the transparent background.)
• Run on Android with Talkback enabled, and try to get to the web view contents.

What I'm seeing is that the webview is completely invisible to Talkback (not only tapping, but if I enable the "dump node tree" option in Talkback developer settings, the resulting tree doesn't list the webview). It appears that this is due to the overlay view that displays the widgets that are over the platform view in the Flutter widget tree (in this case the favorites button); if I run with a local engine modified to not add the overlay view to the Flutter view, it's in the a11y node tree and can be inspected by tapping as expected (although of course other things are broken). It may be that this only happens if there are actually overlays, but I haven't investigated that yet.

The same test works fine in TLHC mode, which is not surprising since we don't use an overlay view for TLHC.

I'm not familiar enough with the internals of Android's a11y system to know why this happens; naively I would expect fully transparent view overlays to mask a11y elements that are underneath them. If possible, we need to find a way to have only the opaque parts of the overlay be treated by the a11y system as hiding what is underneath them. (/cc @chunhtai @bparrishMines )

[stuartmorgan]

Oddly in my maps test (#112662) I'm only seeing that I get hover events for the overlay when I actually tap on the FAB, whereas in the webview example I get them everywhere, even the fully transparent parts. I'm not sure yet what accounts for the difference.

[flutter-triage-bot]

This issue is marked P1 but has had no recent status updates.

The P1 label indicates high-priority issues that are at the top of the work list. This is the highest priority level a bug can have if it isn't affecting a top-tier customer or breaking the build. Bugs marked P1 are generally actively being worked on unless the assignee is dealing with a P0 bug (or another P1 bug). Issues at this level should be resolved in a matter of months and should have monthly updates on GitHub.

Please consider where this bug really falls in our current priorities, and label it or assign it accordingly. This allows people to have a clearer picture of what work is actually planned. Thanks!

[flutter-triage-bot]

This issue is assigned to @johnmccutchan but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!