Tested the issue on mac 10.13.3 using chrome latest stable #67.0.3396.99 and latest canary #69.0.3493.0.

Attached screen casts for reference.

Following are the steps followed to reproduce the issue.
------------
1. Opened chrome browser.
2. Enabled #views-browser-windows from chrome://flags.
3. Observed that on enabling voice over, omnibox suggestions did not work.
4. By setting #views-browser-windows from chrome://flags as default, observed that omnibox suggestions worked properly without any issues. For example, search suggestion, 2 of 6 e.t.c

aleventhal@ - Could you please check the attached screen casts with and without mac views enabled and please let us know if the issue is seen on enabling mac views only. Any further inputs from your end will help us in triaging the issue further.

Thanks...!!

Deleted: 863887@M67_macviews_notenabled.mp4 800 KB

	863887@M67_macviews_notenabled.mp4 800 KB View Download

Deleted: 863887@M67_macviewsenabled.mp4 1.1 MB

	863887@M67_macviewsenabled.mp4 1.1 MB View Download

This is because there's no analogue in OmniboxViewViews to this hack:

  void OmniboxViewMac::AnnounceAutocompleteForScreenReader(
      const base::string16& display_text) {
    NSDictionary* notification_info = @{
      NSAccessibilityAnnouncementKey : base::SysUTF16ToNSString(display_text),
      NSAccessibilityPriorityKey : @(NSAccessibilityPriorityHigh)
    };
    // We direct the screen reader to announce the friendly text.
    NSAccessibilityPostNotificationWithUserInfo(
        [field_ window],
        NSAccessibilityAnnouncementRequestedNotification,
        notification_info);
  }

Doing this causes VoiceOver to read the posted announcement instead of the text changed message. We might need an analogous hack in OmniboxViewViews.

It might be useful to understand how this has been implemented on Windows:
1) The name of each option that gets selected is the friendly text -- see https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_result_view.cc?sq=package:chromium&g=0&l=318
2) After an up/down keypress, we temporarily act like the value of the text field is the full "friendly text" -- see https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_view_views.cc?q=omnibox_view_views&sq=package:chromium&l=911

#2 was added because of some annoying verbalizations when we move focus back and forth between the textfield and the list.

I'm not sure why neither of these work in the MacViews version.

"RBS" as this is P1 blocking MacViews launch.

Looks like the "value changed" notification we're firing from the text field isn't doing anything. This can be verified by disabling the kTextSelectionChanged notification in views::Textfield. Selection changes coupled with stale values seem to be causing this behavior (on the bright side, Safari does the same thing!)

Seems like what we need to do here is add an explicit announcement as in Cocoa.

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

commit 50a15b487e4fcebdf87ca58aa75a420c04dc25f2
Author: Leonard Grey <lgrey@chromium.org>
Date: Thu Jul 19 21:33:42 2018

MacViews a11y: Announce omnibox suggestions on keyboard navigation

Currently, when a user is navigating the omnibox suggestion list, we send two (handled)
accessibility events:
- Value changed
- Selection changed (that is: the empty selection at the end of the text is in a different
position because the string is a different length).

On macOS, the "value changed" event is not triggering an announcement. However, the "selection
change" event does, which causes odd behavior: the system reads a substring of a stale value,
typically the previously selected suggestion. Safari behaves in a similar way, so I think this
is less us doing something wrong and more VoiceOver being quirky.

This change invokes an explicit announcement of the suggestion text, similar to how it's currently
handled in Cocoa.

To facilitate this, this change adds a new Mac-only[1] code path to the views accessibility system
that allows directly specifying text for an accessibility announcement. Alternatives considered:
- Always announcing text field value changes explicitly. This is probably overkill.
- Adding a new native event to ax::mojom::Event to allow for sending arbitrary announcements.
This has the problem that events can't carry arguments so there needs to either be some implicit
convention for which attribute the announcement text is from, or extensive special casing every
time an announcement is added.

In practice, some substrings still get read from the selection announcement, but we have no
straightforward way to suppress it. However, the suggestions are now read in full, so the
impact from the noise is relatively small.

[1] Mac-only due to time constraints since the linked bug is RBS.


Bug:  863887 
Change-Id: Iff220dff63e327d864bd5e5fbeb4523fab37bd94
Reviewed-on: https://chromium-review.googlesource.com/1142031
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#576640}
[modify] https://crrev.com/50a15b487e4fcebdf87ca58aa75a420c04dc25f2/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/50a15b487e4fcebdf87ca58aa75a420c04dc25f2/ui/accessibility/platform/ax_platform_node.h
[modify] https://crrev.com/50a15b487e4fcebdf87ca58aa75a420c04dc25f2/ui/accessibility/platform/ax_platform_node_mac.h
[modify] https://crrev.com/50a15b487e4fcebdf87ca58aa75a420c04dc25f2/ui/accessibility/platform/ax_platform_node_mac.mm
[modify] https://crrev.com/50a15b487e4fcebdf87ca58aa75a420c04dc25f2/ui/views/accessibility/view_accessibility.h
[modify] https://crrev.com/50a15b487e4fcebdf87ca58aa75a420c04dc25f2/ui/views/accessibility/view_ax_platform_node_delegate.cc
[modify] https://crrev.com/50a15b487e4fcebdf87ca58aa75a420c04dc25f2/ui/views/accessibility/view_ax_platform_node_delegate.h

Able to reproduce the issue on Mac 10.13.3 using chrome build without fix.

Verified the fix on Mac 10.13.3 using latest chrome version #69.0.3497.0 as per the comment #0.
Attaching screen cast for reference.
observed that omnibox suggestions worked properly without any issues by enabling #views-browser-windows from chrome://flags.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 863887.mp4 945 KB

	863887.mp4 945 KB View Download

Can this be marked as fixed now if nothing else is pending?

[Auto-generated comment by a script] We noticed that this issue is targeted for M-69; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-69 label, otherwise remove Merge-TBD label. Thanks.

No merge necessary, this landed in 3497