Version: 56.0.2924.87

Note that the focus issues don't occur on Chrome OS. I can use ChromeVox to focus the mic icon button and hear the spoken feedback "listening for ok google", which is more helpful. The only thing is, it's still not implemented as a button, so I don't hear any verbalization that it's a clickable button (across platforms). 

Depends on changes by NTP team.

treib@: does the local NTP fix this issue? if not, can you route it to someone to make sure it gets handled in local NTP?

The local NTP should be mostly identical to the remote NTP at this point.

1) I think this has been fixed in the meantime, or else I don't understand what the problem is. The focus looks fine to me, both on local and remote NTP.

2) On the remote NTP, the microphone has 'aria-label="Search by voice"', on the local NTP is has 'title="Search by voice"' instead. I don't know if either of those resolves the problem, or what else needs to be done.

3) I guess I can see the problem, but I don't follow the suggested solution. What would you like to happen?

4) This one is actually fixed by the local NTP: We never silently close the overlay; instead you get some sort of error message. ("Didn't catch that, try again" or "check microphone levels" or possibly something else, depending on the exact circumstances.)

lpalmaro or hwi, please look at comment 9 above and/or re-try on chrome-search://local-ntp/local-ntp.html - I think 1, 2, and 4 are fixed, and I don't know what can be done about 3.

+leberly, could you help test 1, 2, and 4 for c9 and c10. And also, could you help find ways to address #3? Thanks!

Google Chrome 64.0.3278.0 (Official Build) canary (64-bit) (cohort: Clang-64)
Windows 10 Enterprise Version 1607 Build 14393.1770
JAWS 2018.1710.42 private preview release

Hello,

I am testing these changes using Windows + JAWS screen reader since our team is putting a new emphasis on Windows in the near future and this bug is cross-platform. 

lpalmaro@ and/or a Dev on our team will need to address the ARIA tag choice. I'm going to just repro the behavior for now. 

By testing in Canary, I know I am using the local NTP per this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=775965&desc=3

Note, if I follow this link indicated above (chrome-search://local-ntp/local-ntp.html), the voice search feature is not shown. There is no icon for it. Therefore, I'm just using Canary 64 for this test. 

Steps I used:

# Launch Canary and JAWS
# Launch local NTP since I am in Canary 64
Test 1 - fixed
# Navigate to the Search by Voice icon. 
Expected: focus ring is around the icon itself and "Search by Voice" is spoken. 
Actual: matches expected, this is fixed on Windows

Test 2 - not fixed
# Press space and enter keys to try to activate the button
Expected: button is pressed
Actual: focus is brought to the search box in the middle of the page. Note that is is not the real Omnibar at the top of the browser but the image of one in the middle. 

Test 3 - not fixed
# Use the mouse to press the button since it wasn't possible via keyboard
# Listen for indication about what is happening
# On the first time, I am presented with a dialog and it is read: "www.google.com has a permission request. dialog To navigate use Tab."
# Accept the permission
# Go back to NTP and press button for voice search again. 
Expected: Earcon or some indication that the microphone is listening
Actual: Nothing is spoken unless you press arrow keys to read what's on screen. Since the text comes and goes quickly, the user is unlikely to catch the "listening" message before it is gone. 

Test 4 - not fixed 
# After the listening fails, I am brought back to the NTP. Focus is on the Search by Voice icon.
# Nothing is spoken
Expected: indication that you are back on the NTP
Actual: no way to know you're back on the NTP unless you start navigating around and realize it indirectly by exploring the new context. 

> By testing in Canary, I know I am using the local NTP per this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=775965&desc=3
> 
> Note, if I follow this link indicated above (chrome-search://local-ntp/local-ntp.html), the voice search feature is not shown. There is no icon for it. Therefore, I'm just using Canary 64 for this test. 

This sounds weird, and I suspect you were actually testing the remote NTP, which would explain why 2 and 4 weren't fixed. Note that the local NTP is enabled by default only for 50% of Dev/Canary right now.

To enable the local NTP, you can enable the following two flags:
chrome://flags/#use-google-local-ntp
chrome://flags/#voice-search-on-local-ntp
(and restart Chrome as prompted).

To verify whether you're seeing the remote or the local NTP, on an NTP do right-click -> "View page source" and look at the Omnibox:
- If it says "view-source:chrome-search://local-ntp/local-ntp.html": Local NTP
- If it says "view-source:https://www.google.com/_/chrome/newtab?ie=UTF-8": Remote NTP

Could you test 2 and 4 again with the two flags above set? (We haven't addressed 3 yet, so no point in testing again.) Thanks, and sorry for the trouble!

Ping, please see comment 13.

Update:
I am now testing with the following:
Google Chrome 65.0.3322.0 (Official Build) canary (64-bit) (cohort: Clang-64)
Windows 10 Enterprise Version 1607 Build 14393.2007
NVDA 2017.4
JAWS 2018.1801.18 Private Beta 
 
Local NTP by enabling the following two flags:
chrome://flags/#use-google-local-ntp
chrome://flags/#voice-search-on-local-ntp

Under View Source on NTP, file is called"chrome-search://local-ntp/local-ntp.js" and there is no mention of the remote NTP. 

Steps I used to retest tests 2 and 4:

# Launch Canary with local NTP per statements above
# Test using JAWS, NVDA, and keyboard-only

Test 2 - 
# Press space and enter keys to try to activate the button
Expected: button is pressed
Actual: button is pressed

Note that the permissions dialog is read by JAWS but not by NVDA. 

Test 4 - not fixed 
# After the listening fails, I am brought back to the NTP. Focus is on the Search by Voice icon. 
# Nothing is spoken
Expected: indication that you are back on the NTP
Actual: no way to know you're back on the NTP unless you start navigating around and realize it indirectly by exploring the new context. 
I can repro nothing being spoken with JAWS and NVDA.

I noted that the NVDA focus rectangle is still on the same area of the page the entire time the listening information is on the screen. It's as if NVDA didn't know that the page content had changed at all. 

Thanks for re-testing!


Re 2:
By "permissions dialog", you're referring to the "google.com want to: Use your microphone" popup? If so, then that probably isn't specific to the NTP, but the same will apply for any web page that requests microphone permission. So I don't think the NTP can do anything about that.


Re 4:
Just to confirm we're talking about the same thing: You click the microphone button and see the "Speak Now"/"Listening" message. After a few seconds with no input, the "Please check your microphone and audio levels" message shows up. After another few seconds, that message vanishes and you're silently dropped back to the NTP <- this is where the problem is.

I'm not sure about a solution. Is there a good way to indicate "voice search was closed, you're back on the NTP"? Or maybe we should just not automatically close the overlay when some assistive technology is active (per BrowserAccessibilityState::IsAccessibleBrowser())?


Re NVDA focus rectangle: I think that's essentially bug 779300, i.e. the voice search overlay isn't properly marked as a "dialog".

Repros in 69.0.3497.23 (Official Build) dev (64-bit) (cohort: Dev)	
JAWS 2018.1807.29 ILM	
NVDA 2018.2.1

See also button specific bug: https://bugs.chromium.org/p/chromium/issues/detail?id=870729&desc=2

Update after syncing with Laura:

1 and 2 are fixed but 3 and 4 are not yet fixed. They are not blockers but would be a nice usability improvement.

Current behavior: Press "voice search" button and get verbal announcement for web content.

Expected behavior: First, Earcon that signals to user that we are listening. Second, if you press the icon and it didn't understand you, it should also signal that to you.

^ Ideal would be to slot those into 71 or 72 so that we can reach accessibility goals by the end of the year.

Giving this an update/repro with Chrome OS and ChromeVox as part of our assessment. It has slightly worse behavior. 

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

I am running these tests on the NTP that comes out of the box in M70 with no flags set. 

Enabling ChromeVox with ctrl + alt + z

Test 1 - NOT fixed
# Navigate to the Search by Voice icon. 
Expected: focus ring is around the icon itself and "Search by Voice" is spoken as a button. 
Actual: ChromeVox says "Search by Voice Form" instead of "Search by Voice Button"

Test 2 - technically NOT fixed
# Press space and enter keys to try to activate the button
Expected: hint text spoken about using search + space to invoke button, button is pressed
Actual: Button is indeed pressed but there is no text spoken about how to invoke it. 

Test 3 - not fixed
# Go NTP and press button for voice search. 
Expected: Earcon or some indication that the microphone is listening
Actual: ChromeVox reads "times dialog" upon the page loading with no earcon. This in turn is heard by the voice recording and a Google search is automatically opened with the search. No indication that that page has opened automatically. 

Test 4 - not fixed 
# Let listening fail by keeping the computer volume on mute and being silent. I am brought back to the NTP. Focus is on the middle of screen around the Google logo in an indeterminate area. 
# Nothing is spoken
Expected: indication that you are back on the NTP and focus back on the voice search button you previously pressed 
Actual: no way to know you're back on the NTP unless you start navigating around and realize it indirectly by exploring the new context. ChromeVox focus is in incorrect place. 

I think Kristi has looked at this in the past.

Updating the current behavior in c30, including differences between remote and local NTP:

Local NTP:
Re 1 - fixed, ChromeVox says "Search by Voice Button"
Re 2 - fixed, search + space hint is spoken and can select with search + space
Re 3 - not fixed, same as before
Re 4 - not fixed, same as before
Note: Using search + tab to navigate to the omnibox will not close the dialog.

Remote NTP:
Re 1 - not fixed, same as before
Re 2 - not fixed, same as before
Re 3 - not fixed, same as before
Re 4 - not fixed, same as before
Note: Using search + tab to navigate to the omnibox will automatically close the dialog.

The voice search dialog for remote NTP is also used in the main Google search page. However, the microphone icon is not accessible with voice over/keyboard, so our changes shouldn't have too much effect.

(re-adding label)

The NextAction date has arrived: 2018-11-14

To clarify, would the earcon sound bytes be audio_end/initiate.wav in https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/sounds/earcons/?

The NextAction date has arrived: 2019-01-22