Also reproduces on Google_Lulu.6301.136.57 on 69.0.3494.0 (Official Build) dev (64-bit)

Lulu seems to be less severe with the ctrl + alt + z toggle working about 2/3 of the time. 

Would be great to try and get a bisect range. This is definitely a recent regression.

Does not reproduce on Eve in 67.0.3396.99 (Official build)(64-bit)

Working to get narrower range. 

Does not reproduce in 68.0.3440.76 on Eve

As FYI, the bisect-builds.py script has a -a chromeos option. Unsure if you've used it before (it only works on linux). Let me know and thanks again for pinning this down!

Thanks, I'm trying to download and install some intermediate builds given the severity of this bug. 

Also, I don't have a Linux machine (dsexton@ and lprazdnik@ also don't have one.)

I'm in the middle of more testing but I wanted to mention that I'm monitoring events using rbyers.github.io/eventTest.html and I saw at least one instance where the OS got my keystrokes while ChromeVox ignored them. 

This does not appear to be a recent regression. 

I had a hunch that just trying to repro for a few times on the older builds might not have been enough to catch the behavior since it is intermittent overall. I took a closer look. 

Steps:
# Log in with Chromium account 
# Press ctrl + alt + z once every four seconds 20 times in a row. That is, 10 times to turn on and 10 times to turn off. (I got a metronome for the timing.) I used consistent pressure and watched that the keys were in fact pressed in. 
# Count how many times the key presses didn't work out of the set of 20. 

67.0.3396.99 on Eve: missed 3/20. The first two attempts to turn on did nothing.
 
68.0.3440.76 on Eve: missed 5/20. The first two attempts to turn on did nothing.

I did another set of 20 on 68: missed 5/20 again. The first two attempts worked.

I did another set of 10 on 68, this time with the event logging page running in the 
background: ChromeVox missed 7/10 times but the OS received all expected key events for the three keys. 

The problem is worse while this page is active. 

On 68, I had more failures for ChromeVox to get the keypresses, up to 6 times in a row where the events page logged the key presses or keydowns and key releases but ChromeVox did nothing. 

Moving onto 69 for comparison. 

Google Chrome	69.0.3494.0 (Official Build) dev (64-bit)
Google Eve.9584.160.0

The key event page is https://rbyers.github.io/eventTest.html 

Testing on the login screen, set of 20: missed 13/20. The first two attempts were ignored except that a "z" character was entered into the password field each time. After that, when they were ignored, there were no characters entered into the password field. 

Signing in, without loading the key event page, set of 20: missed 9/20

I then uninstalled the one extension I was running, screencastify. 
Signed in, with the key event page loaded in the background, set of 20: missed 8/20. 

Based on the triage information, this does not appear to be a regression issue with M69. What is the impact and is it a RBB for M69? If so, an owner needs to be assigned. Thank you.

Per #9, this is not recent regression and not a M69 regression. Owner needs assigned and details for RBB for M69 provided. Removing the blocking label; if you feel this is not the correct action please provide an update. Thank you.

This was tested on Eve and Lulu, with Corp and Chromium accounts, on 67, 68, and 69. 

Current expectation is:
- press ctrl+alt+z
- only after you hear "ChromeVox spoken feedback enabled", is ChromeVox actually considered enabled.

This is by design. It, for example, would not make sense to repeatedly toggle ChromeVox repeatedly (say, within 1 second intervals).

I found the root cause! I was using non-allowed combinations such as ctrl + z + alt. I'm going to file a feature request to change the documentation to make it clear to always use modifier keys then regular keys.