I can repro, but it's not really related to ChromeVox. When the on-screen keyboard is showing, it obscures the ubertray, but the ubertray is still focusable.

I'm not even sure what the right behavior is here. Albert, can you delegate this?

It was caused by enabling over-scrolling on accessibility keyboard.
For a user not enabling ChromeVox, ubertray behind the VK has no access.
I'm also not sure what the right behavior is in this case.

Omri, what is the right behavior here?

This is indeed a weird thing. While in the previous state it was slightly better behavior than now, both options are not really expected as when the on screen keyboard is open, the Uber tray as defined today is hidden as part of the whole shelf being hidden. 
If I’m not mistaken, we have wanted tabs to not interact with things that are not in the screen, or in other words, we want tabs to interact with the visible content. 

I’m tempted to say that we shouldn’t traverse over Uber tray at all while the on screen keyboard is expanded, and instead just have the traversal reach the close button. 

That being said, such a change would require more thinking and a UI review. 

For now I’d encourage reaching something like the previous state, which is having the shelf be hidden by the auto-complete area of the virtual keyboard, and therefor having the quick settings open directly above the keyboard. Just like before. 

Thoughts?

Also, not sure this qualifies as a P1. Laura, correct me if I’m wrong. 

This bug has a target milestone that has passed.  Please help bug cleanup: mark it closed or update/remove the milestone target. 

I'm closing this as there is a workaroud (dismiss the keyboard) and declaring the regression "overcome by events" as it's now 10 milestones old.  If specific problems arise, we can re-address.