This was not really the bisect I was expecting here

https://chromium.googlesource.com/chromium/src/+log/15659facd055987d4e5253ea49d548ddbb3a58fb..1cdbef88a7ade4a852488ea26ee3af26efdedda6

Will try reverting some of these in a bit, but in the meantime +ccameron@

(and I did the bisect twice to be sure so, ¯\_(ツ)_/¯ ?)

Culprit confirmed as https://chromium-review.googlesource.com/c/chromium/src/+/1071117

More specifically, RenderWidgetHostViewMac::SetParentUiLayer is breaking things.

Theorizing that this is related
https://bugs.chromium.org/p/chromium/issues/detail?id=833638#c5

In  issue 840173 , we merged the compositors. This means that
- RenderWidgetHostViewMac is a transparent NSView, and is only used for input
- a ui::Layer to the browser's ui::Compositor for display

Prior to this change, the browser somehow "knew" to delegate VoiceOver to the RenderWidgetHostViewMac for that region of the screen. I would guess that having added the ui::Layer for display-only is confusing this. Who is a good owner for VoiceOver who I can ask more about this integration?

I don't think we have anyone with really deep knowledge of this (especially since it's so opaque on our end).

I'm trying different things right now to make the tree coherent on the theory that fixing Issue 833638 may help, but even with no changes, RWHVC *is* being queried for accessibility attributes when the relevant page elements are being interacted with, but nothing is being read on the VoiceOver end, and the accessibility focus isn't traveling to web content.

ccameron@ is this key part? https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_ns_view_bridge.mm?type=cs&sq=package:chromium&g=0&l=146

What does it do in practice?

I tried an experiment where I kept the CALayers and NSViews unchanged (so RWHVMac is transparent), but I didn't add the ui::Layer from BrowserCompositorMac to the tree.

The result was that VoiceOver started working again (even though nothing was being displayed). This suggests that something going through the ui::Layers is deciding not to delegate a11y to the RWHVMac.

Of note is that NativeViewHostMac::GetNativeViewAccessible return nullptr. Changing this doesn't fix anything, though.

Okay, here's the problem:

BrowserAccessibilityManagerMac::GetParentView tries to get a RenderWidgetHostViewMac's NSView. It's doing this through a delegate interface (it doesn't know it's talking to a RWHVMac).

It does this by calling AccessibilityGetAcceleratedWidget, and materializing a NSView out of that.

For RenderWidgetHostViewMac, "accelerated widget" means "the surface that I'm compositing into". Unifying the RWHVMac and MacViews compositors changed the answer to something unexpected here.

There are a bunch of fixes here
- we can just implement and use AccessibilityGetNativeViewAccessible
- I'd generally prefer not to implement AccessibilityGetAcceleratedWidget, cause there is an impedance mismatch on that interface

ccameron has a CL to resolve this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/19ca521bd06417000994f1a15c008c0b970eb526

commit 19ca521bd06417000994f1a15c008c0b970eb526
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Jun 20 19:00:29 2018

MacViews: Fix VoiceOver failures

BrowserAccessibilityManagerMac::GetParentView is used to get the NSView
for a RenderWidgetHostViewMac (via a delegate interface -- it doesn't
know it's talking to a RenderWidgetHostViewMac).

It does this by calling AccessibilityGetAcceleratedWidget, and then
converting to an NSView via ui::AcceleratedWidgetMac::GetNSView.

Two problems with this approach:
 1. This is roundabout -- the RenderWidgetHostViewMac knows its NSView
    directly.
 2. When the RenderWidgetHostViewMac doesn't do its own compositing,
    this ends up being incorrect. The gfx::AcceleratedWidget used by
    compositing is the same as the main window. There exists no
    gfx::AcceleratedWidget mapped to the RenderWidgetHostViewCocoa.

Change BrowserAccessibilityManagerMac::GetParentView to call the
delegate method AccessibilityGetNativeViewAccessible, which returns an
NSView directly.

Remove the implementation of AccessibilityGetAcceleratedWidget, since it
will lead to trouble.

Bug:  852781 
Change-Id: I74985d678f3cb10128a0e2caeb17fb3f22aa1752
Reviewed-on: https://chromium-review.googlesource.com/1105502
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568960}
[modify] https://crrev.com/19ca521bd06417000994f1a15c008c0b970eb526/content/browser/accessibility/browser_accessibility_manager_mac.mm
[modify] https://crrev.com/19ca521bd06417000994f1a15c008c0b970eb526/content/browser/renderer_host/browser_compositor_view_mac.h
[modify] https://crrev.com/19ca521bd06417000994f1a15c008c0b970eb526/content/browser/renderer_host/browser_compositor_view_mac.mm
[modify] https://crrev.com/19ca521bd06417000994f1a15c008c0b970eb526/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/19ca521bd06417000994f1a15c008c0b970eb526/content/browser/renderer_host/render_widget_host_view_mac.mm

Unable to verify the fix on chrome version 69.0.3493.0 using Mac 10.13.1 as we are unable to reproduce the issue on earlier versions (i.e., later versions of M68 and initial versions on M69) with the exact steps mentioned in comment#0.

@Christopher Cameron: Could you please help us in verifying the fix.

Thanks!

Re: c#15

--enable-features=ViewsBrowserWindows

Enable VoiceOver (Command-F5), navigate to web content and confirm that VoiceOver is reading web content.

Verified the fix on chrome version 69.0.3494.0 using Mac 10.13.1 as per comment #16.
Attaching screen cast for reference.
Observed that Voice over is working when #views-browser-windows is enabled.
Hence, the fix is working as expected. 
Adding the verified labels.
Note: Able to reproduce the issue on chrome version(69.0.3464.0) with out fix.

Thanks...!!

Deleted: 852781 CL Verification.mp4 1.6 MB

	852781 CL Verification.mp4 1.6 MB View Download

Issue is reproducible on the latest beta 68.0.3440.59 on Mac OS 10.13.3.  

ccameron@: Shall we get the fix merged to M-68?