Google Chrome 66.0.3357.2 (Official Build) canary (64-bit) (cohort: 64-Bit)
Google Chrome 64.0.3282.186 (Official Build) (64-bit) (cohort: Stable Installs Only)
Windows 10 Enterprise Version 1607
JAWS 2018.1802.78 ILM 64-bit English
NVDA 2017.4
This bug only repduces with a screen reader on, it doesn't reproduce with keyboard only. It is also timing dependent and intermittent so I'll describe both how to reproduce it and similar actions that won't reproduce it.
# Launch JAWS, Chrome and any Google Doc
# Make sure focus is in the Doc editing area
# Press and hold alt then press and hold f
This will launch the Docs file menu as expected.
# Put focus back into the Docs editing area. If you don't do this step and press alt + f again while the focus is on the Docs menu or if the focus is anywhere else on the page, the Chrome menu will open - this behavior is currently by design from the Docs team.
# Very quickly do the following: press and hold alt, press and hold f, then release alt while still holding down f. If you do this slowly it won't reproduce at all. The best way I can describe to perform this action is as if you're playing fast notes on a piano: roll your fingers on the alt and f keys on the keyboard.
About 50% of the time using this very fast method I described, you'll see that the focus lands on the Docs File menu and the menu expands for a split second before collapsing again and focus landing on the Chrome menu. A screen reader user would have no way of knowing this is happening.
# Close JAWS, launch NVDA, repeat the above steps. Repro rate is about 30%, a little less often than with JAWS.
Here's a bit of research to provide the background for this bug:
In Chrome on any page such as about:blank, if you press and release the alt key the focus lands on the Customize and Control Chrome menu icon. If you press and hold Alt + f or Alt + e on about:blank, the Chrome menu is focused AND the menu expands visually. For a screen reader user, however, there is no difference between these two since focus remains in the same place. Here's the Chrome documentation for that: https://support.google.com/chrome/answer/157179?hl=en
Documentation for Google Docs/Sheets etc. keyboard shortcuts says that for
File Menu
in Google Chrome: Alt + f
other browsers: Alt + Shift + f
https://support.google.com/docs/answer/181110
One reason this is the case is to prevent keystroke collisions in Chrome OS. The Alt + Shift keys are already in use in Chrome OS for key features like opening the launcher or opening help per this documentation: https://support.google.com/chromebook/answer/183101?hl=en
The internal discussion on expected behavior for these keystrokes with Chrome + screen readers + Google Docs/Drive is tracked in b/73955753
Google Chrome 66.0.3357.2 (Official Build) canary (64-bit) (cohort: 64-Bit)
Google Chrome 64.0.3282.186 (Official Build) (64-bit) (cohort: Stable Installs Only)
Windows 10 Enterprise Version 1607
JAWS 2018.1802.78 ILM 64-bit English
NVDA 2017.4
This bug only repduces with a screen reader on, it doesn't reproduce with keyboard only. It is also timing dependent and intermittent so I'll describe both how to reproduce it and similar actions that won't reproduce it.
# Launch JAWS, Chrome and any Google Doc
# Make sure focus is in the Doc editing area
# Press and hold alt then press and hold f
This will launch the Docs file menu as expected.
# Put focus back into the Docs editing area. If you don't do this step and press alt + f again while the focus is on the Docs menu or if the focus is anywhere else on the page, the Chrome menu will open - this behavior is currently by design from the Docs team.
# Very quickly do the following: press and hold alt, press and hold f, then release alt while still holding down f. If you do this slowly it won't reproduce at all. The best way I can describe to perform this action is as if you're playing fast notes on a piano: roll your fingers on the alt and f keys on the keyboard.
About 50% of the time using this very fast method I described, you'll see that the focus lands on the Docs File menu and the menu expands for a split second before collapsing again and focus landing on the Chrome menu. A screen reader user would have no way of knowing this is happening.
# Close JAWS, launch NVDA, repeat the above steps making sure to turn off browse mode using insert + space before testing. Cannot repro in NVDA (see comment 3 below for more details.)
Here's a bit of research to provide the background for this bug:
In Chrome on any page such as about:blank, if you press and release the alt key the focus lands on the Customize and Control Chrome menu icon. If you press and hold Alt + f or Alt + e on about:blank, the Chrome menu is focused AND the menu expands visually. For a screen reader user, however, there is no difference between these two since focus remains in the same place. Here's the Chrome documentation for that: https://support.google.com/chrome/answer/157179?hl=en
Documentation for Google Docs/Sheets etc. keyboard shortcuts says that for
File Menu
in Google Chrome: Alt + f
other browsers: Alt + Shift + f
https://support.google.com/docs/answer/181110
One reason this is the case is to prevent keystroke collisions in Chrome OS. The Alt + Shift keys are already in use in Chrome OS for key features like opening the launcher or opening help per this documentation: https://support.google.com/chromebook/answer/183101?hl=en
The internal discussion on expected behavior for these keystrokes with Chrome + screen readers + Google Docs/Drive is tracked in b/73955753
Google Chrome 66.0.3357.2 (Official Build) canary (64-bit) (cohort: 64-Bit)
Google Chrome 64.0.3282.186 (Official Build) (64-bit) (cohort: Stable Installs Only)
Windows 10 Enterprise Version 1607
JAWS 2018.1802.78 ILM 64-bit English
NVDA 2017.4
This bug only repduces with a screen reader on, it doesn't reproduce with keyboard only. It is also timing dependent and intermittent so I'll describe both how to reproduce it and similar actions that won't reproduce it.
# Launch JAWS, Chrome and any Google Doc
# Make sure focus is in the Doc editing area
# Press and hold alt then press and hold f
This will launch the Docs file menu as expected.
# Put focus back into the Docs editing area. If you don't do this step and press alt + f again while the focus is on the Docs menu or if the focus is anywhere else on the page, the Chrome menu will open - this behavior is currently by design from the Docs team.
# Very quickly do the following: press and hold alt, press and hold f, then release alt while still holding down f. If you do this slowly it won't reproduce at all. The best way I can describe to perform this action is as if you're playing fast notes on a piano: roll your fingers on the alt and f keys on the keyboard.
About 50% of the time using this very fast method I described, you'll see that the focus lands on the Docs File menu and the menu expands for a split second before collapsing again and focus landing on the Chrome menu. A screen reader user would have no way of knowing this is happening.
# Close JAWS, launch NVDA, repeat the above steps making sure to turn off browse mode using insert + space before testing. Cannot repro in NVDA (see comment 3 below for more details.)
Here's a bit of research to provide the background for this bug:
In Chrome on any page such as about:blank, if you press and release the alt key the focus lands on the Customize and Control Chrome menu icon. If you press and hold Alt + f or Alt + e on about:blank, the Chrome menu is focused AND the menu expands visually. For a screen reader user, however, there is no difference between these two since focus remains in the same place. Here's the Chrome documentation for that: https://support.google.com/chrome/answer/157179?hl=en
Documentation for Google Docs/Sheets etc. keyboard shortcuts says that for
File Menu
in Google Chrome: Alt + f
other browsers: Alt + Shift + f
https://support.google.com/docs/answer/181110
One reason this is the case is to prevent keystroke collisions in Chrome OS. The Alt + Shift keys are already in use in Chrome OS for key features like opening the launcher or opening help per this documentation: https://support.google.com/chromebook/answer/183101?hl=en
The internal discussion on expected behavior for these keystrokes with Chrome + screen readers + Google Docs/Drive is tracked in b/73955753
Google Chrome 66.0.3357.2 (Official Build) canary (64-bit) (cohort: 64-Bit)
Google Chrome 64.0.3282.186 (Official Build) (64-bit) (cohort: Stable Installs Only)
Windows 10 Enterprise Version 1607
JAWS 2018.1802.78 ILM 64-bit English
NVDA 2017.4
This bug only repduces with a screen reader on, it doesn't reproduce with keyboard only. It is also timing dependent and intermittent so I'll describe both how to reproduce it and similar actions that won't reproduce it.
# Launch JAWS, Chrome and any Google Doc. Be sure to turn off the virtual cursor with Insert + Z.
# Make sure focus is in the Doc editing area
# Press and hold alt then press and hold f
This will launch the Docs file menu as expected.
# Put focus back into the Docs editing area. If you don't do this step and press alt + f again while the focus is on the Docs menu or if the focus is anywhere else on the page, the Chrome menu will open - this behavior is currently by design from the Docs team.
# Very quickly do the following: press and hold alt, press and hold f, then release alt while still holding down f. If you do this slowly it won't reproduce at all. The best way I can describe to perform this action is as if you're playing fast notes on a piano: roll your fingers on the alt and f keys on the keyboard.
About 50% of the time using this very fast method I described, you'll see that the focus lands on the Docs File menu and the menu expands for a split second before collapsing again and focus landing on the Chrome menu. A screen reader user would have no way of knowing this is happening.
# Close JAWS, launch NVDA, repeat the above steps making sure to turn off browse mode using insert + space before testing. Cannot repro in NVDA (see comment 3 below for more details.)
Here's a bit of research to provide the background for this bug:
In Chrome on any page such as about:blank, if you press and release the alt key the focus lands on the Customize and Control Chrome menu icon. If you press and hold Alt + f or Alt + e on about:blank, the Chrome menu is focused AND the menu expands visually. For a screen reader user, however, there is no difference between these two since focus remains in the same place. Here's the Chrome documentation for that: https://support.google.com/chrome/answer/157179?hl=en
Documentation for Google Docs/Sheets etc. keyboard shortcuts says that for
File Menu
in Google Chrome: Alt + f
other browsers: Alt + Shift + f
https://support.google.com/docs/answer/181110
One reason this is the case is to prevent keystroke collisions in Chrome OS. The Alt + Shift keys are already in use in Chrome OS for key features like opening the launcher or opening help per this documentation: https://support.google.com/chromebook/answer/183101?hl=en
The internal discussion on expected behavior for these keystrokes with Chrome + screen readers + Google Docs/Drive is tracked in b/73955753
Here's the exact verbalization from JAWS and NVDA in these states:
JAWS normal state:
menu
File
1 of 9
To move through items press up or down arrow.
JAWS error state:
Chrome button menu
Customize and control Google Chrome
Press space to activate the menu, then navigate with arrow keys
NVDA normal state:
document
about:blank
File subMenu 1 of 9
NVDA error state:
document
about:blank
no next form field
Chrome menu button subMenu Customize and control Google Chrome
The plot thickens! There are times when visually the Docs file menu is expanded but it turns out focus is on the Chrome menu when you use the screen reader to navigate. It appears Chrome took the focus before the Docs menu had time to react and collapse its file menu.
Here's another insight! I forgot to turn off browse mode using insert + space and when I did so, I can no longer reproduce this problem with NVDA.
However, before I did that, NVDA gives a hint of what might be happening at least on its end. Here's the breakdown of what happens with NVDA when focus is in the edit area of a Google Doc:
In NVDA, if you press and release just Alt, the focus goes to the Chrome menu no matter what. This is expected. Also in NVDA if you forget to turn off browse mode like I did, if you press and release f, it looks for the next form field, also expected.
It appears due to the error state verbalization listed above that NVDA is performing BOTH actions in succession when alt is released. That is, instead of passing the alt + f keystroke to Docs, it's instead passing Alt to Chrome and f to look for the next form field.
Comment 1 by leberly@chromium.org
, Mar 1 2018