Should reproduce with any recent version of Chrome and Jaws 18 or 2018 or any versions of NVDA.

Steps to reproduce.
On Win 7, open Chrome and visit a website.
Press Ctrl+D to add a bookmark.
Notice that focus jumps into something that you can't navigate with Jaws or NVDA. NVDA says "Unknown".

I feel this is an a11y bug since it works well with keyboard/mouse but the popover information is not shown to a screen reader user. Here is the content not read by the screen reader upon pressing the generate password option:

There is a picture of a key and then "Use a strong password generated by Chrome" then an example strong password. 
Below that, it says "Chrome will save this password with Google Smart Lock. You don't have to remember it."

You can reproduce on Windows 10 by starting Chrome with --disable-dwm-composition

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

commit ac2debc64eccfbfd17c66ed8be6a07b2aea36481
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Tue Dec 12 07:24:17 2017

NativeViewAccessibilityWin::GetParent should support transient parents.

To post an accessibility event on a NativeViewAccessibilityWin,
we call NotifyWinEvent on the owning HWND, and pass it the
negation of its unique ID as the child ID argument. The
assistive technology then fetches the IAccessible by calling
get_accChild on the HWND's IAccessible and passing it that
child ID.

In AXPlatformNodeWin::get_accChild, we do a sanity check that
the child found is a descendant of the HWND, so we don't
return a View from a different window by mistake. We do this
by walking up from the descendant using GetParent() to make
sure we reach the root.

This is failing for bubbles on Windows 7 because they're
implemented as transient windows (windows with a parent
window set, but with child=false), and
NativeViewAccessibilityWin::GetParent wasn't correctly
walking up from a child widget to its transient parent.

Fix this by taking transient windows into account, and
update an existing unit test that wasn't fully testing
this case correctly, to make it correct and have it test
both cases (child = false and child = true).

Bug:  785628 
Change-Id: I17ea2f5b24c75a9aae7e93a669ac84db8e8feb90
Reviewed-on: https://chromium-review.googlesource.com/818390
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523363}
[modify] https://crrev.com/ac2debc64eccfbfd17c66ed8be6a07b2aea36481/ui/views/accessibility/native_view_accessibility_win.cc
[modify] https://crrev.com/ac2debc64eccfbfd17c66ed8be6a07b2aea36481/ui/views/accessibility/native_view_accessibility_win_unittest.cc

Requesting a merge to M64 based on several user bug reports

Your change meets the bar and is auto-approved for M64. Please go ahead and merge the CL to branch 3282 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Has this been merged yet?

This slipped through the cracks, sorry - is it okay to merge or too late?

how critical is this fix? We need to ensure that it's well tested, safe, and good to go. We're only 4 days away from Stable now so if we can wait until M65, that'll be better. 

friendly ping