It looks like the chat is rendered in an iframe, and we just found a bug where all iframe contents aren't read out at all ( crbug.com/770248 , added to blocking). As a hack for demos, etc you can turn on "Native accessibility API support" in chrome://accessibility to get iframes to work with select-to-speak.

Re Basic HTML view: Looks like gmail is creating a button to go to a "basic html view" which it will display visually to the user when the page is loading slowly. That button has 0 size but we seem to be assigning it a size anyway in the accessibility tree.

Specifically, in ax_tree.cc RelativeToTreeBounds we set the bounds to the container bounds if they are size 0. Maybe here we should check that the object should even have size -- are the bounds set to 0 in css / on purpose? Or maybe there's somewhere earlier in building the tree that added this node with non-zero size incorrectly?

I tried putting some logging at the very end of AXObject::GetRelativeBounds to see if that was setting the bounds incorrectly, but it seems it always sets bounds to 0x0.

String name = ComputedName();
if (name == "Basic HTML view") {
  LOG(ERROR) << ComputedName() << out_bounds_in_container.ToString();
}

So I think the problem may be because of RelativeToTreeBounds.

Regarding "Basic HTML View": 
Here's where it was made size (0,0) in gmail: https://critique.corp.google.com/#review/68387852. The gmail team wants users with screen readers to be able to tab-navigate to this element. However, they probably don't want Select-to-speak users to find the element because it should have no size.

In ax_tree.cc, the change to make the bounds equal to the container bounds came from https://bugs.chromium.org/p/chromium/issues/detail?id=756788. I'm thinking it would be better if nodes of 0 size had size (1, 1) bounds. It seems like a developer wouldn't explicitly set a thing to be size (0, 0) unless they didn't want it to be visible to users except for screen readers.

"Basic HTML view" and iframe problems fixed. 

Reassigning to Laura -- any other blocking or big issues with gmail and select-to-speak?

Just circling back here. This is a big improvement. The remaining items I noticed last week when testing were specifically around the email draft. Basically, when you try to use StS to read the contents of a new draft, StS reads what is behind the draft and not actually what's inside of it. This was the biggest remaining item I noticed in Gmail but will keep using it! 

Marking fixed because I think I've got the draft email issue fixed! Should be in a Canary near you shortly.

Moving from just having STS label to also having the UI>Accessibility>SelectToSpeak component to make searching easier in the future.