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


Does not repro with ChromeVox, title is read when focus is in the dev tools, though the title itself is overly verbose. 

NVDA(modifier key)+T "Reports the title of the currently active window" per documentation. When the DevTools are docked in the existing window the current window title is the original tab title (so NVDA+T reading the original tab title sounds like it's working as expected).

When DevTools is not docked in the current window (is its own stand-alone window), NVDA+T reads "DevTools - https://bugs.chromium.org/p/chromium/issues/detail?id=864768 - pbos@google.com" for this bug. I think pbos@google.com comes from my profile name.

It sounds to me like this is working as intended (the window title is being read in both cases). I can't repro NVDA+T not reading the window title, is this WAI?

Perhaps a better announcement when dev tools opens would be helpful as well as an easier way to dismiss dev tools.
Currently, when I press f12, NVDA says 'Highlights from the Chrome 70 update'
Nowhere in that window do I find anything that says what has just opened for example 'dev tools'
I also don't find a way to close the window

If NVDA said something like 'dev tools, press f12 to close' this would be helpful.

It would be nice to also allow escape to close dev tools when docked as that would be one of the first things I'd try to close it.

There should be a way to set the name of the dev tools window similar to the omnibox, bookmarks bar, and downloads bar.

To hear the names of these areas of the UI:
# With NVDA or JAWS running, press f6 repeatedly to cycle between the omnibox, bookmarks bar, webpage, and dev tools.
Notice that dev tools only says 'document'
It should say 'dev tools'

Thanks, that perfectly clarifies it. cyan@ PTAL :)

I tried to do this in the Views layer, but it seems that both the contents pane and the developer tools pane delegate all of their a11y behavior to the WebView. I'm going to pass this issue to someone who has done significant work in the WebView a11y sphere and see if they can't triage the problem/hand it off to someone who can address it directly.

I don't know; I haven't done accessibility work in recent years, just approval stamping.

Nektarios, do you know who might be at the intersection of WebView and accessibility?

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.