Harmony (chrome://flags/#secondary-ui-md) has the same issue. 
Tested on Canary 64.0.3243.1, Win10, NVDA

Setting to p2 since this was found during our assessment

I think this might be a good first bug for David to get a bit more familiar with the dialog framework (the actual fix is probably finding where the button is instantiated + mark it as focusable).

leberly@: Is the policy in general that all buttons should be keyboard accessible even if there are keyboard shortcuts for doing the same things? You can do the equivalent action (closing the button) by pressing escape. Is it handy for screenreader users if the dialog close button is in the focus ring even if there is a commonly-used shortcut for closing it?

I still think including the close button in the focus order could be a good thing (or is at least not a bad thing), just wanted to know the reasoning behind it.

I did a quick search and it looks like this behavior is intended:

https://cs.chromium.org/chromium/src/ui/views/bubble/bubble_frame_view.cc?type=cs&sq=package:chromium&l=153

Comment reads:

  // Remove the close button from tab traversal on all platforms. Note this does
  // not affect screen readers' ability to focus the close button. Keyboard
  // access to the close button when not using a screen reader is done via the
  // ESC key handler in DialogClientView.

Is this desired (and is it true w/r/t screenreaders)?

Agree that the behavior was intended - change was made for this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=741251&desc=2

and it looks like the the goal was to have consistent behavior across windows/mac/linux.

Re: c8 "...wanted to know the reasoning behind it."

The reasoning is the following from the description:
"Although ESC key can close the popover, when the user is in keyboard navigation mode using SR navigation key or Tab key, being able to focus on Close [x] is more convenient than moving fingers to ESC."

+tapted@, any concerns with making the close button focusable on all platforms instead of none? You get the same platform consistency. :)

to add to c#11: I also assume that this is a similar case for non-SR keyboard navigation.

From what I understand, a popover is a non-modal dialog that appears inside Chrome's main window. Tab and Shift+Tab keys take you through the controls in the popover, but escape out of the popover as well to cycle through the rest of the Chrome UI, e.g. Back and Forward buttons.
If my understanding is correct, then it is not at all clear that one should press escape to close the popover, because as far as they are concerned the main window is Chrome and esc never closes a main window. Users will learn via experience that esc will do the job, but from my experience I wouldn't know that.

Unless the SR focus order is different from normal order, Tab / Shift+Tab cycles inside the popover dialog and does not take you to the browser screen (back, forward, etc are not reachable w/ tab and shift-tab only).

I think we should err on the side of what a11y/SR users prefer here, so unless tapted@ has strong objections I'd have us change the close button to always be focusable.

Certainly on Mac, screen reader focus order is different. Otherwise you could never focus a label to read it out :). With VoiceOver turned on, CapsLock+Left twice currently focuses the close [x], and CapsLock+Space will activate it.

Windows 10 Narrator does something similar. The focus order is a bit weird, but (e.g. on the bookmarks bubble) Caps+Up moves up out of the text field, then Caps+Right eventually will focus the close [x] and it can be activated.

Tab never focuses the "traffic light" buttons on Mac to close native windows, so it seems odd for it to focus the close [x] on Chrome dialogs (IMO).

Is this maybe a bug in NVDA?

(big disclaimer: I am not a regular screen-reader user so I have no idea what the best behaviour is).

I vote for closing as WontFix. Screen reader users can already navigate to the close button, and keyboard users can press Escape.

Closing per #18, reopen if you strongly feel otherwise.

 Issue 816835  has been merged into this issue.