New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 875843 link

Starred by 12 users

Issue metadata

Status: Verified
Owner:
Closed: Oct 8
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug
Team-Accessibility



Sign in to add a comment

Live regions have regressed with VoiceOver

Project Member Reported by aleventhal@chromium.org, Aug 20

Issue description

Steps:
Load a live region file such s the attached, with VoiceOver running

Actual:
Live regions not spoken

Expected:
Live regions spoken

This is a regression as it worked in Chrome 68.

 

Comment 1 Deleted

The regression was caused by:
https://chromium-review.googlesource.com/c/chromium/src/+/1138793 
which was landed to fix  issue 861756  and issue 833638
live-voiceover-weird.html
639 bytes View Download
This change that you're implicating says it's for MacViews.

Are you saying that it regressed non-MacViews live regions also?

Cc: phanindra.mandapaka@chromium.org ellyjo...@chromium.org dmazz...@chromium.org aleventhal@chromium.org pbomm...@chromium.org
 Issue 876395  has been merged into this issue.
@dmazzoni, yes, there is at least one non-MacViews regression with a different timeline. It's really intermittent, but definitely worse than it used to be. I tried bisecting but couldn't get a perfect signal of good vs. bad. Strangely, the farther back in time you go, the better it works, but it's really hard to say when something 'broke'.
Project Member

Comment 7 by bugdroid1@chromium.org, Aug 28

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

commit 649d9d389cb5593c7432bbd63dbb25965dbbdbcc
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Tue Aug 28 01:19:13 2018

Clean up window roles in AX object ancestry chain for UI

Use the group role rather than a second window role for the root view,
in order to avoid having a parent and child that both have a window
role, which can confuse VoiceOver's attempts to find the web content.

Bug:  875843 
Change-Id: Ic28c1898a965caa966413bdb948523a8e526ba79
Reviewed-on: https://chromium-review.googlesource.com/1191086
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586532}
[modify] https://crrev.com/649d9d389cb5593c7432bbd63dbb25965dbbdbcc/ui/accessibility/platform/ax_platform_node_mac.mm
[modify] https://crrev.com/649d9d389cb5593c7432bbd63dbb25965dbbdbcc/ui/views/widget/ax_native_widget_mac_unittest.mm

Status: Fixed (was: Started)
This appears to have fixed the issue completely in Mojave.

Unfortunately, it will remain mostly broken in pre-Mojave. The user needs to sometimes quit and relaunch Chrome. Not sure what, if anything, we can do about that.
 Issue 868731  has been merged into this issue.
Cc: vamshi.kommuri@chromium.org
 Issue 882443  has been merged into this issue.
Cc: viswa.karala@chromium.org
 Issue 887524  has been merged into this issue.
Mojave is still technically an unreleased OS:

Release date: September 24, 2018

That means that for normal uses who rely on VoiceOver for accessibility the web is kinda broken :(
Cc: susan.boorgula@chromium.org
 Issue 889979  has been merged into this issue.
@aleventhal

Even quitting and re-launching as you mentioned in #8 doesn't seem to have any impact in my testing.  So is the final position here is that this functionality will just continue to remain broken, and it will be up to the user to upgrade to Mojave to regain the functionality?
This needs to be fixed for Macs that can't be upgraded to Mojave, e.g. older machines or those which are restricted from installing OS updates due to company or school policies. Failing to do so will likely cause my company to stop recommending Chrome for our VoiceOver users.
Marking this bug as fixed when it clearly is not does not demonstrate a commitment to making the web accessible for all users.
Status: Assigned (was: Fixed)
I understand the frustration and thank you for voicing your concerns.

I'll try to revisit this. Note that this is due to a VoiceOver bug that we have not found a workaround for. Even in Safari, if you open a new tab, live regions stop working pre-Mojave.

Steve, in comment 8, I should have said the user needs to quit and relaunch VoiceOver.
@aleventhal

Just to be clear about the current behavior I'm seeing, using the following URL as test case:
https://minorninth.github.io/aria-live-region-tests/live_region_tests.html

Safari Version 12.0 (13606.2.11) / Mac OS 10.13.6 (17G65) [High Sierra]
Result: aria-live regions are read correctly in Voiceover

Chrome Version 69.0.3497.100 (Official Build) (64-bit) / Mac OS 10.13.6 (17G65) [High Sierra]
Result: No aria-live regions are announced

Yes, I am aware of the VoiceOver bug with Safari— in fact I filed this issue with Apple during the Mojave development cycle, and it’s definitely less problematic now than before. I fully accept that pre-Mojave, this issue can’t be completely fixed, but I would hope that restoring the functionality in Chrome 68 and earlier would be a realistic compromise.
The behavior I am experiencing in Chrome is that VoiceOver does not work with live regions in Chrome _at all_.  It seems to have nothing to do with opening a new tab or anything like that.  I can start a new Chrome process and only have a single tab open and the live regions are still not announced.
I'm going to put in a hack that will use the announce API when it's in OS X <= 10.13 (pre-Mojave). It has shortcomings but basically works:
- will cause a beep sound when a live region is announced. These can be muted in VoiceOver settings (VoiceOver Utility) -> Sounds -> Mute sound effects
- will not support aria-atomic

In Mojave the full live region support will continue to be there.

I'm interested in people's feedback on this. I know it's not ideal but it's unclear how to fully fix the issue without this. Believe me I spent time on it and we're talking about working around bugs in the OS. The reason it worked before Chrome 68 is unclear -- we had a vastly different window architecture then. Hope this is enough.
If all goes well this will be in tomorrow's Canary for people to test.
Thank you. If this works as described, I, for one, can live with it.
Project Member

Comment 24 by bugdroid1@chromium.org, Sep 28

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

commit f0f6d1aecbe7ea8e6dfbedd8656beaafab86072b
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Fri Sep 28 20:15:19 2018

Announce API as workaround for live region bugs in MacOS <= 10.13 (pre-Mojave)

In some versions of MacOS, live regions don't work consistently, due to a bug
in those versions of VoiceOver. Due to these bugs, use the announce API when
running on an older version of MacOS.

Bug:  884801 , 875843 
Change-Id: Ia9711cf935ba605785dfb3cfaf32f85bd2c8cf13
Reviewed-on: https://chromium-review.googlesource.com/1228635
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595193}
[modify] https://crrev.com/f0f6d1aecbe7ea8e6dfbedd8656beaafab86072b/content/browser/accessibility/browser_accessibility.cc
[modify] https://crrev.com/f0f6d1aecbe7ea8e6dfbedd8656beaafab86072b/content/browser/accessibility/browser_accessibility.h
[modify] https://crrev.com/f0f6d1aecbe7ea8e6dfbedd8656beaafab86072b/content/browser/accessibility/browser_accessibility_manager_mac.mm

I'm glad to have found this issue. I'm also seeing the issue where aria-live regions do not work at all on Chrome Stable (Version 69.0.3497.100 (Official Build) (64-bit)) on macOS High Sierra.

However, they do seem to be working for me on Canary (Version 71.0.3560.0 (Official Build) canary (64-bit) and Version 71.0.3564.0 (Official Build) canary (64-bit)).
I've landed the workaround described in comment 21, in Canary, for pre-Mojave MacOS.

Please let me know if it is an acceptable workaround.
 Issue 884801  has been merged into this issue.
As a follow up, testing with Version 69.0.3497.100 (Official Build) (64-bit) still doesn't work (as expected).

Testing with Version 71.0.3573.0 (Official Build) canary (64-bit) works. The only difference I see between this build and my previous tests (Version 71.0.3560.0 (Official Build) canary (64-bit) and Version 71.0.3564.0 (Official Build) canary (64-bit)) is that there is now a soft chime when the announcements occur. This seems acceptable to me.

I would really like this fix to go into Chrome 70 as this has a significant impact on the a11y of AngularJS Material.

Thank you!
Yes, there is a soft ding sound but this goes away in Mojave and later.

Here is a quote from a Google employee who uses VoiceOver every day: "Yes, the sound does get annoying after a while, but I am not sure we have much alternative, plus users of High Sierra lived with this "earcon" issues for quite a while (it is as annoying with other apps that rely on announcements). If I had a vote, I'd say, please please push it through and let's do the explanations later. :)"
Labels: Merge-Request-70
Project Member

Comment 31 by sheriffbot@chromium.org, Oct 8

Labels: -Merge-Request-70 Merge-Review-70 Hotlist-Merge-Review
This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Benefits of a merge: necessary for accessibility of many products that really in live regions, including Google Docs, when used in pre-op Mojave MacOS. The regression was originally caused by MacViews changing the window hierarchy, which greatly exacerbated a bug in VoiceOver that is fixed in Mojave. 

Accessibility team tried many other ways to fix it and didn't find any. This ended up being pretty simple approach.

Without the fix there was a fair amount of concern from the community received here and via email, compared with the usual volume of feedback we get for accessibility bugs.


Thanks for the fix!

Few questions: Is this a new regression in M70, or has this been present before? Which CL needs to be merge, and how safe and well tested is this? Are there any concerns about introducing new regressions?


> Few questions: Is this a new regression in M70, or has this been present before? 
It first broke in 69, and unfortunately made it to stable.

> Which CL needs to be merge, and how safe and well tested is this? 
I actually recommend we land both of the two CL's.
The first one is https://chromium-review.googlesource.com/c/chromium/src/+/1191086 and fixes this for Mojave and beyond. This one has been baking since August 27.
The second CL is https://chromium-review.googlesource.com/c/chromium/src/+/1228635 and fixes this for pre-Mojave. This one has been baking since September 28.

As far as testing, a fair number of accessibility users/tests stay on Canary in order to get the latest fixes. As you can see both CLs, the fixes sre rather small and simple. We haven't learned anything about either CL to make us think they are unsafe or do not work as intended.

> Are there any concerns about introducing new regressions?
No

Labels: -Merge-Review-70 Merge-Approved-70
Ok great thanks - approving merge to M70. The first CL should have already landed since we branched on Aug 30th. 

Approving second CL in #34.
Thanks, that's right about the first CL already being in M70, I forgot for a moment there.
Project Member

Comment 37 by bugdroid1@chromium.org, Oct 8

Labels: -merge-approved-70 merge-merged-3538
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d389d4fe072bd375282d82a63f2ceb243cda2d9e

commit d389d4fe072bd375282d82a63f2ceb243cda2d9e
Author: Aaron Leventhal <aleventhal@chromium.org>
Date: Mon Oct 08 23:06:17 2018

Announce API as workaround for live region bugs in MacOS <= 10.13 (pre-Mojave)

In some versions of MacOS, live regions don't work consistently, due to a bug
in those versions of VoiceOver. Due to these bugs, use the announce API when
running on an older version of MacOS.

Bug:  884801 , 875843 
Change-Id: Ia9711cf935ba605785dfb3cfaf32f85bd2c8cf13
Reviewed-on: https://chromium-review.googlesource.com/1228635
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#595193}(cherry picked from commit f0f6d1aecbe7ea8e6dfbedd8656beaafab86072b)
Reviewed-on: https://chromium-review.googlesource.com/c/1270075
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#908}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/d389d4fe072bd375282d82a63f2ceb243cda2d9e/content/browser/accessibility/browser_accessibility.cc
[modify] https://crrev.com/d389d4fe072bd375282d82a63f2ceb243cda2d9e/content/browser/accessibility/browser_accessibility.h
[modify] https://crrev.com/d389d4fe072bd375282d82a63f2ceb243cda2d9e/content/browser/accessibility/browser_accessibility_manager_mac.mm

Status: Fixed (was: Assigned)
Labels: TE-Verified-70.0.3538.54 TE-Verified-M70
Able to reproduce the issue on chrome version 70.0.3528.0 (build without fix) as per the comment #0.
Verified the fix on Mac 10.12.6  using Chrome version # 70.0.3538.54.
Attaching screen-cast for reference.
As we are able here that "Live regions spoken" 
The fix is working as expected, adding Verified labels

Thanks..!
875843.mp4
2.1 MB View Download
Status: Verified (was: Fixed)

Sign in to add a comment