This dialog is a bubble, most likely "SessionCrashedBubble"

I already closed another bug about the Close button as WontFix because the Escape key works fine, and the close button is already accessible to screen readers (using object navigation).

Do you agree or do you think the close button needs to be in the tab order?

Can you find some examples of dialogs in other applications that have a close button that's in the tab order?

Note that the close button in a standard Windows top-level window isn't in the tab order. Why should this be different? If there's a good reason I think we need to figure out how to articulate why a little more clearly.

I think for me because it's not in the center of the window and it's so persistent on the right side even after opening a new tab, it never dawned on me that esc would get rid of it. It doesn't quite fit - it's not a modal and it's not tied to another piece of the UI like the Omnibox or the menu. 

It does seem more of its own window which wouldn't make sense in the tab order nor would it seem to close with esc. If it were a standard top level window, I'd kill it with alt + F4 which wouldn't work here.

However, putting it in a tab order I'm willing to let this be closed if either it was somehow made clearer to users on how to close it or it wasn't so persistent. What do you think?

69.0.3497.23 (Official Build) dev (64-bit) (cohort: Dev)	
JAWS 2018.1807.8 ILM	
NVDA 2018.2.1

This still reproduces. The thing about this dialog is that it is unlike all the others, it is not anchored to anything. The dialog is also read out but focus is not brought to it to be able to invoke the restore button. See attached screenshot. 

JAWS speech upon opening after crash:
 Alert!
Restore pages?
Restore pages?
Close
Chrome didn’t shut down correctly.
Restore

Pressing tab brings focus to the page itself, not this dialog. 

Deleted: restorepages.png 16.6 KB

	restorepages.png 16.6 KB View Download

Partially reproducible on Chrome OS

Google Chrome	69.0.3497.35 (Official Build) dev (64-bit)
Firmware Version	Google_Lulu.6301.136.57

ChromeVox does read this dialog upon it appearing. It also lets you linear navigate to read the rest of the dialog. However, if you take focus off the dialog there is no way to go back to it to dismiss it. 

Considering that it's possible to press escape, or it's possible to open a new tab instead without the restore UI, I think this is okay to close out with the idea that there are bigger fish to fry. :) Please reopen if you feel strongly otherwise! 

Maybe this is better for another bug, but my takeaway from these comments is that since the restore dialog does not close when the focus is lost, it should navigate into the dialog (and maybe the exit and restore button inside) from the AppMenuButton when pressing tab.
I think this should be a higher priority /re-opened since it is really easy to lose focus on the restore bubble (minimizing, moving the window) and sometimes Chrome opens with the focus already on the Omnibox thus making it impossible to navigate to the restore bubble.

Good point, if the bubble stays open when focus is away from it, we should be able to get to it.

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

commit a29a6af4c1c58b81b9b033b25e36ddf5ce641021
Author: Peter Boström <pbos@chromium.org>
Date: Thu Oct 25 01:47:12 2018

Fix focus traversal into BubbleDialogDelegateView

This change makes sure that:

* Focus traversal is enabled for BubbleDialogDelegateView instances that
  have their anchor view set in the constructor (before it's being added
  to a Widget).
* Focus traversal can continue from views with children into the
  anchored dialog if no focusable views are found within the dialog.
  Before this change you could only reverse-focus (shift-tab) into the
  anchored dialog (if it was anchored to a view that had child views).

This resolves focus traversal into at least the "Restore pages?" crash
dialog and "Extension X is disabled" dialogs, but the fixes are generic
and a class of dialogs should now be focus traversable as a result of
these two changes.

Bug:  chromium:810601 
Change-Id: Ia480a3039eb6d41480f4ef759d099fd9e88c33a7
Reviewed-on: https://chromium-review.googlesource.com/c/1297595
Commit-Queue: Peter Boström <pbos@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602568}
[modify] https://crrev.com/a29a6af4c1c58b81b9b033b25e36ddf5ce641021/chrome/browser/ui/views/accessibility/invert_bubble_view_browsertest.cc
[modify] https://crrev.com/a29a6af4c1c58b81b9b033b25e36ddf5ce641021/ui/views/bubble/bubble_dialog_delegate_view.cc
[modify] https://crrev.com/a29a6af4c1c58b81b9b033b25e36ddf5ce641021/ui/views/bubble/bubble_dialog_delegate_view.h
[modify] https://crrev.com/a29a6af4c1c58b81b9b033b25e36ddf5ce641021/ui/views/focus/focus_manager_unittest.cc
[modify] https://crrev.com/a29a6af4c1c58b81b9b033b25e36ddf5ce641021/ui/views/focus/focus_search.cc

FWIW this should solve a class of anchored dialogs not being reachable / in tab order, so other dialogs not mentioned here might be automagically fixed as well.

Chrome: 72.0.3604.0 (Official Build) canary (64-bit) (cohort: Clang-64)

Steps to repro:
# Crash chrome as in original post
# Start chrome again
# focus the restore dialog by pressing alt+d, then tab
# Press tab again

Expected: Close button receives focus, then document receives focus if tab is pressed again

Actual: Focus is trapped on the restore button

Close buttons never receive focus (as bubbles can be closed with ESC).

We trapped focus inside this bubble along with making it consistent with other dialogs, like the bookmarks dialog. There are several dialogs that close when they lose focus so letting focus escape everywhere is not an option.

Do we need to add an exception to the restore-pages dialog, or can we let the user use ESC to escape it, like they would other dialogs?

Closing, please reopen if you have a reason to make an exception to this dialog specifically. Now focus stays inside the dialogs.

Able to repro still in Canary channel:
Google Chrome:72.0.3624.2 (Official Build) canary (64-bit) (cohort: Clang-64)
OS: Windows 10 Enterprise version 10.0.1.16299
Steps to repro:
1. Load Chrome with a few tabs 
2. unexpectedly close Chrome by going into Task Manager and killing the process 
3. Open Chrome, 
4. JAWS keeps reading restore pages but cursor never goes to the restore option 
Also noted that and tab does not read aloud the actual elements of the pages rather just reads aloud tab, tab 

JAWS speech upon opening after crash:
 Alert!
Restore pages?
Restore pages?
Close
Chrome didn’t shut down correctly.
Restore

I think the last JAWS speech entry shows "Restore" as the restore button. It's just really hard to see that the blue Restore button is focused (this is  issue 900774 ).

Canary on Windows 10, 73.0.3629.0:

1. Open a few tabs.
2. Kill Chrome in Task Manager
3. See Restore pages? dialog
4. Hold <tab> for a while, focus is now on the "Restore" button (which I assume is the last entry in your sequence).
5. Click spacebar => all pages are restored.