It's fixed in 62.0.3180.0 but haven't been merged back. I'll merge it today and we can check again.

From what I can see, some texts (including the account email address) appear at the top of the screen after pressing Ctrl+Alt+Z. Is it expected? Or is the issue referring to the lack of sound in particular?

If we're seeing text displayed at the top then it should be working.

Hi all, we're targeting a Beta next week so we need fixes and/or workarounds submitted by COB Monday 8/14 if this is still considered a beta blocker.  Possible?  Is this confirmed as resolved and tagged for a M61 merge?   Thanks!

I checked the CL fixing this was landed before branch date, https://chromium-review.googlesource.com/c/578459 in 61.0.3163.0. So 61.0.3163.30 should already contain the fix and it's not reproducible on my side. If you can still repo this please reopen and it needs additional investigation. 

I'm still seeing this on 61.0.3163.38.
Laura, David, can you help us investigate?

zalcorn@ Have we noticed this on any more devices? or is this just the one device you are currently seeing it on?

I've seen this on multiple Eve devices.

Just Eve?   Restricted to Eve only?

Haven't tried on other devices - does someone have another device on dev chanel that could test

Is this really a beta block for all devices?

This is strange. I remembered seeing the issue on Eve in a recent M62 build, but I can't repo anymore today using various builds. There seems to be a race.

The Canary that I tried but cannot repo:

Platform:       Chrome Version:
9765.16.0       61.0.3163.30
9765.28.0	61.0.3163.41  (Latest M61 Canary)
9841.0.0	62.0.3176.0   (Latest M62 Canary)
9841.0.0	62.0.3186.0   (ToT)

zalcorn@ can you try to repro on today's build and close this out if we can't repro it anymore?

I can repo in today's build. (9765.29.0, 61.0.3163.47)

After re-installing the same image, the issue disappears. I didn't find anything suspicious in the log.

I don't have more insights for now. All we know is that this issue sometimes appears in Eve, but never on other boards.

If we don't have a consistent repro let's at least remove the RBB label. let us continue to triage.

crbug.com/746568

Totally a beta block...

ChromeVox users can no longer sign in. I would consider that an issue. 

To update, the cl that supposedly fixed login issues with ChromeVox in
crbug.com/746568
made things worse by entirely removing the password input from the accessibility tree. Let's revert that cl to get back to a working state.
I can reproduce this 100% of the time.
The expected behavior is for the password input to get focus, for typed keys to get echoed e.g.
password for David... textifled
<type>
bullet bullet ...
etc.

David, feel free to revert the CL... but I don't think it will solve this issue.. I already tried manually reverting that CL, but the issue is still there. And this issue is not 100% reproducible. At first I could repo using 9765.29.0, 61.0.3163.47, but after re-installing the same image the issue totally disappears. I'm confused.

One thing I can say for sure is.. after the CL first lands in 61.0.3163.0, there is no issue with the text field, and users can use password input field to enter passwords. The changes that's indeed caused by this CL is, password field gets focused one time instead of three times, so the echo of bullets disappears. That's a regression.

So I'm reverting the CL now to see how it goes.

https://chromium-review.googlesource.com/c/617907
https://chromium-review.googlesource.com/c/617770

are two fixes.

Thanks for the revert. I'm about to do the same.

I realize this might be some miscommunication:

1) Per crbug.com/706068, we were explicitly asked to use aria-hidden on images, before a human readable image name becomes available. After the revert users can hear 'images' again. The real issue here is we don't have a proper image name. 

2) That CL never intends to hide password field. We were asked to hide the two extra focuses on the password field. If there's a way to focus it only once yet the echo of dots can still be heard, or you don't mind focusing three times, that would be the best.

3) We can't consistently repo this current issue. I can't repo it right now even with the CL in. If you don't find this issue after the revert, it doesn't mean it's fixed.

When it's broken it's login screen only, but not lock screen... The reverted file is shared between login and lock screens though.. and it's only seen on Eve... strange

David, I realize we are actually talking about two different things. What this issue tracks is that ChromeVox is 'completely unusable' (including both login screen and add new user flow), which occurs occasionally, only on Eve. Maybe you never encountered with that if you are not using Eve.

I think what you're referring to is 'password field lacking focus'. Reverting the CL will fix it, but again it will be focused three times. Before landing the CL I explicitly checked that the password field was still editable despite of only being focused once. What I observed is, although the input field itself is hidden, when you navigate to the password field, the cursor will still appear, so it won't prevent you from entering password. It seems that you didn't get the cursor in your case, which may suggest yet another issue. Anyways I understand the input field is not supposed to be hidden, and that CL removes the image label and the echo of dots, which were intended at that time but are considered as regression now, so reverting the CL makes sense.

As for this issue, I'll let you know the next time it's reproducible.

I just flashe eve to latest beta and it crashes immediately after boot after a stateful clobber, so no accessibility involved. I can't be sure ChromeVox causes the issues, because it seems like eve is just unstable without accessibility being involved.

Yes, sorry, we are indeed talking about two issues. I am confused by your usage of "focus". There is only ever one DOM focus. The page itself incorrectly sets focusable the div wrapping the input. The issue I think you were seeing with "password" being repeated multiple times has to do with the way the page is constructed:
- the outer div is focusable and has a label of "password for ..."
- the password input itself has a label
- the password input has a placeholder

Each of these pieces of text gets exposed to ChromeVox. I uploaded a cl to remove the placeholder from the accessibility tree since it is exposed as an attribute on the input. The div is a page authoring issue.

Ignoring the input is perhaps a separate bug, but it was a direct result of this bug and imo, is a blocker since it affects all devices and prevents a user from knowing they can log in (i.e. the password field has focus and input is being registered).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/65b53fd9a6d64ae0b9c3672779c69247e08e71d4

commit 65b53fd9a6d64ae0b9c3672779c69247e08e71d4
Author: David Tseng <dtseng@chromium.org>
Date: Fri Aug 18 17:58:57 2017

Fix bad aria-hidden usage

Aria-hidden was set to true for lots of meaningful elements including the password input. The result is that all of this content is invisible.
For the images, the author should provide a human readable string in the alt attribute.
For the input, this should *never* be invisible exclusively to accessibility. The potentially confusing part is that the DOM has a lot of aria labels set higher up in the node tree. In particular, the parent of the <input> has an aria label of "Password for ...", so someone trying to fix this might incorrectly assume that having the <div> non-aria hidden is sufficient. It unfortunately isn't. It would be best to at some point clean all of this up.

Here's what the live markup after all the js runs looks like:

"<div class="password-entry-container">
          <div class="password-container" aria-label="Password for <omitted>@gmail.com">
            <input type="password" class="password" placeholder="Password" tabindex="1">
          </div>

          <div class="capslock-hint-container">
            <iron-icon class="capslock-hint" icon="user-pod:caps-lock">
            </iron-icon>
          </div>
          <paper-icon-button class="submit-button" disabled="" aria-label="Submit" icon="user-pod:arrow-forward" tabindex="-1" role="button" aria-disabled="true" style="pointer-events: none;">
          </paper-icon-button>

        </div>"

Test: ChromeVox can actually see the input password, and typing echos characters on focus.
Bug:  753463 
Change-Id: I7beedae79b18333e41d0c66ccd6e565844c8918f
Reviewed-on: https://chromium-review.googlesource.com/617907
Reviewed-by: Wenzhao (Colin) Zang <wzang@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Commit-Queue: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495613}
[modify] https://crrev.com/65b53fd9a6d64ae0b9c3672779c69247e08e71d4/ui/login/account_picker/md_user_pod_template.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a9584c51d093c6c9c657bad06df55a50f710536c

commit a9584c51d093c6c9c657bad06df55a50f710536c
Author: David Tseng <dtseng@chromium.org>
Date: Fri Aug 18 23:26:49 2017

Ignore placeholder text in Accessibility tree

Bug:  753463 
Test: when navigating text fields with a placeholder, this makes it so we don't get stuck. With ChromeVox with a working login screen, Search+right. Verify that we don't get stuck on the password text field.
Change-Id: Iae13558bdb513a733a2273e86770acfff3e11027
Reviewed-on: https://chromium-review.googlesource.com/617770
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495742}
[modify] https://crrev.com/a9584c51d093c6c9c657bad06df55a50f710536c/content/test/data/accessibility/aria/input-text-aria-placeholder-expected-blink.txt
[modify] https://crrev.com/a9584c51d093c6c9c657bad06df55a50f710536c/content/test/data/accessibility/html/actions-expected-blink.txt
[modify] https://crrev.com/a9584c51d093c6c9c657bad06df55a50f710536c/content/test/data/accessibility/html/input-text-expected-blink.txt
[modify] https://crrev.com/a9584c51d093c6c9c657bad06df55a50f710536c/content/test/data/accessibility/html/input-text-name-calc-expected-blink.txt
[modify] https://crrev.com/a9584c51d093c6c9c657bad06df55a50f710536c/content/test/data/accessibility/html/input-text-read-only-expected-blink.txt
[modify] https://crrev.com/a9584c51d093c6c9c657bad06df55a50f710536c/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c0636d736762c4da1bd01240e042a908b7f9eed

commit 1c0636d736762c4da1bd01240e042a908b7f9eed
Author: David Tseng <dtseng@chromium.org>
Date: Mon Aug 21 17:35:38 2017

Ignore placeholder text in Accessibility tree

TBR=dtseng@chromium.org

(cherry picked from commit a9584c51d093c6c9c657bad06df55a50f710536c)

Bug:  753463 
Test: when navigating text fields with a placeholder, this makes it so we don't get stuck. With ChromeVox with a working login screen, Search+right. Verify that we don't get stuck on the password text field.
Change-Id: Iae13558bdb513a733a2273e86770acfff3e11027
Reviewed-on: https://chromium-review.googlesource.com/617770
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#495742}
Reviewed-on: https://chromium-review.googlesource.com/623918
Reviewed-by: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#702}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/1c0636d736762c4da1bd01240e042a908b7f9eed/content/test/data/accessibility/aria/input-text-aria-placeholder-expected-blink.txt
[modify] https://crrev.com/1c0636d736762c4da1bd01240e042a908b7f9eed/content/test/data/accessibility/html/actions-expected-blink.txt
[modify] https://crrev.com/1c0636d736762c4da1bd01240e042a908b7f9eed/content/test/data/accessibility/html/input-text-expected-blink.txt
[modify] https://crrev.com/1c0636d736762c4da1bd01240e042a908b7f9eed/content/test/data/accessibility/html/input-text-name-calc-expected-blink.txt
[modify] https://crrev.com/1c0636d736762c4da1bd01240e042a908b7f9eed/content/test/data/accessibility/html/input-text-read-only-expected-blink.txt
[modify] https://crrev.com/1c0636d736762c4da1bd01240e042a908b7f9eed/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/644abe6621b1d2c26219868e0a3773e9b29e5d18

commit 644abe6621b1d2c26219868e0a3773e9b29e5d18
Author: David Tseng <dtseng@chromium.org>
Date: Mon Aug 21 17:40:42 2017

Fix bad aria-hidden usage

Aria-hidden was set to true for lots of meaningful elements including the password input. The result is that all of this content is invisible.
For the images, the author should provide a human readable string in the alt attribute.
For the input, this should *never* be invisible exclusively to accessibility. The potentially confusing part is that the DOM has a lot of aria labels set higher up in the node tree. In particular, the parent of the <input> has an aria label of "Password for ...", so someone trying to fix this might incorrectly assume that having the <div> non-aria hidden is sufficient. It unfortunately isn't. It would be best to at some point clean all of this up.

Here's what the live markup after all the js runs looks like:

"<div class="password-entry-container">
          <div class="password-container" aria-label="Password for <omitted>@gmail.com">
            <input type="password" class="password" placeholder="Password" tabindex="1">
          </div>

          <div class="capslock-hint-container">
            <iron-icon class="capslock-hint" icon="user-pod:caps-lock">
            </iron-icon>
          </div>
          <paper-icon-button class="submit-button" disabled="" aria-label="Submit" icon="user-pod:arrow-forward" tabindex="-1" role="button" aria-disabled="true" style="pointer-events: none;">
          </paper-icon-button>

        </div>"

TBR=dtseng@chromium.org

(cherry picked from commit 65b53fd9a6d64ae0b9c3672779c69247e08e71d4)

Test: ChromeVox can actually see the input password, and typing echos characters on focus.
Bug:  753463 
Change-Id: I7beedae79b18333e41d0c66ccd6e565844c8918f
Reviewed-on: https://chromium-review.googlesource.com/617907
Reviewed-by: Wenzhao (Colin) Zang <wzang@chromium.org>
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Commit-Queue: David Tseng <dtseng@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#495613}
Reviewed-on: https://chromium-review.googlesource.com/624182
Reviewed-by: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#703}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/644abe6621b1d2c26219868e0a3773e9b29e5d18/ui/login/account_picker/md_user_pod_template.html

Folks I'm still seeing issues with Chromevox on Sign-In screen in M72, what remaining work is there to fix this?

Zach, what issues did you see in particular? I can traverse all the elements using Tab and everything has a proper label.

Video at go/crbug-773839-vid - it's behaving very strangely for me on my Caroline. Not vocalizing anything, sometimes showing labels and sometimes not. Not sure if it's a Chromevox issue or sign-in screen.

ChromeVox is working fine on my Eve with two users. In your case, will the labels eventually show up if you focus on the user and wait a little bit longer?

I think this is a ChromeVox issue because the accessibility labels are added for the login for sure. Can dtseng@ or jdufault@ help with this issue? 

This seems like an issue in chromevox

Note: The tag on this bug is incorrect; it's supposed to be ReleaseBlock-* with no dash between the Release and Block.

Is this still happening for you zalcorn@?

I'm going to dup this one to a master bug tracking speech issues on the login screen. This has happened from time to time with varying causes, so this bug in particular isn't helpful. The original reproduction is also fixed, so reading the history confuses more than anything. Thanks!