Issue metadata
Sign in to add a comment
|
a11y: certain pages load but the web contents are empty
Reported by
st...@sawczyn.com,
Dec 26 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36 Steps to reproduce the problem: 1. Using a screen reader such as NVDA, browse to: https://www.weightwatchers.com/us/checkout/?cid=eml_US_122617_Online_Lose10_Extra15_122617_Lapsed_Online_Winback_NACO_ExtraSavings&ct=hero&j=761152&sfmc_sub=30954105&l=352_HTML&u=8531653&mid=7003004&jb=210#/plan 2. Use arrow keys to read through the page, or tab to move between interactive elements. 3. What is the expected behavior? Screen readers should be able to read all the content on this page. In addition, pressing tab should move between interactive elements and each element should be announced as it gains focus. What went wrong? Only thing read is, "Weight Watchers choose your plan." Screen readers are unable to access any other content on this page. Did this work before? N/A Chrome version: 63.0.3239.108 Channel: stable OS Version: 10.0 Flash Version: I tested this with both NVDA and Narrator with same results. I've seen this occur on other pages as well, but have not been able to determine any sort of pattern. In all cases where this occurs, I am able to browse the page just fine using other browsers, i.e. Firefox or IE.
,
Dec 27 2017
Thank you for this report and a clear example site. I was able to confirm this issue with NVDA, but not with Jaws. Chrome 65.0.3305.0 (Official Build) canary (64-bit) Firefox 52.5.2 (64-bit) NVDA 2017.4 JAWS 2018 Works as expected with Firefox+NVDA and Firefox+JAWS Works with JAWS + Chrome Canary Does not work with NVDA + Chrome Canary Please let us know if you also experience this issue with JAWS and Chrome.
,
Dec 27 2017
Possibly related to issue 797818 . NVDA is presenting these issues in the same way, but may be different cause.
,
Jan 29 2018
Another URL which exhibits this behavior is: https://fafsa.ed.gov/
,
Feb 7 2018
Another URL exhibiting this is: http://www.envisionamerica.com/
,
Feb 7 2018
,
Feb 8 2018
,
Feb 8 2018
This bug occurs for me with JAWS. It's possible that we are running different versions of JAWS, or that there is a timing issue that causes the bug to sometimes not occur. When the bug occurs, the accessibility hierarchy is not filled out. It only has a document object and no descendant content.
,
Feb 8 2018
Bisecting revealed this change: https://chromium-review.googlesource.com/c/chromium/src/+/699975 Here's an explanation of the root cause: Imagine the web page is initially in this state: rootWebArea body IGNORED button Because the body is ignored, Blink presents this accessibility tree, skipping over the ignored node. rootWebArea button Now the web page adds a click listener to the body. This causes it to be not ignored. So now the button thinks that its parent is the body. However, we never triggered a childrenChanged on the rootWebArea, so it still thinks button is its child, rather than body. So walking down the tree we have rootWebArea -> button, but walking up we have button <- body <- rootWebArea. This inconsistency is what causes the button to not appear in the resulting accessibility tree at all. It's an intentional safeguard to prevent corner cases. The short-term fix is to fire the right events to update the tree to handle this specific case. Longer-term I want to totally redo how we handle ignored nodes in a way that's much more robust and foolproof. This affects all platforms, so I'm renaming the bug and adding multiple platforms
,
Feb 8 2018
,
Feb 8 2018
Here's the smallest repro I can make. Can anyone else confirm that the button on this page is NOT accessible for them too?
<head>
<script>
window.setTimeout(function() {
document.body.addEventListener('mousedown', function() {});
document.documentElement.setAttribute('aria-label', 'Done');
}, 200);
</script>
</head>
<body>
<div>
<button>This should be accessible</button>
</div>
</body>
,
Feb 9 2018
Fix up for review: https://chromium-review.googlesource.com/c/chromium/src/+/910123
,
Feb 9 2018
A user in the mailing list reported this behavior in Mac OSX as well: Same result with VoiceOver in macOS 10.13.3 with both Chrome stable Version 63.0.3239.132 and Chrome Canary 66.0.3341.0. Other notes: 1. While the page title is announced, VO is unable to interact with the page, I am unable to tab into the page, and the web rotor & item chooser list no elements. 2. Refreshing the page makes no difference. 3. Toggling VO off and on seems to restore proper VO access to the page. 4. VO works fine with the same page in the current build of Safari, 11.0.3.
,
Feb 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7dc3a173d256cf3edbca00d8ca2680a4e4b32a97 commit 7dc3a173d256cf3edbca00d8ca2680a4e4b32a97 Author: Dominic Mazzoni <dmazzoni@chromium.org> Date: Fri Feb 09 16:53:04 2018 Fix critical accessibility bug causing page content to be inaccessible In Blink accessibility, when an AXObject is "ignored", it's not included in the accessibility tree. The ignored node's parent includes the ignored node's children directly, leaving it out of the tree. As an example, consider this html: <html><body><div><button/></div></body></html> The current heuristics leave the body element out of the accessibility tree. The accessibility tree looks like: rootWebArea (the html node) genericContainer (the div) button There are many ways for a node that's ignored to become unignored, like adding an id or an ARIA attribute. Typically this fires the right notifications and the node gets spliced into the accessibility tree. The bug in this case is that adding a click listener to an ignored node causes it to be not ignored anymore, but it does not correctly invalidate its parent. In the example above, adding a click listener to the body and then modifying the html element "breaks" the tree. The HTML node thinks its child is the DIV, but the DIV thinks its parent is the BODY. This inconsistency breaks the entire page's accessibility tree. The fix is to catch changes to a node's ignored state and call ChildrenChanged. Bug: 797695 Change-Id: Ib8b077e3ebb96ec1634a847db7477589cde74012 Reviewed-on: https://chromium-review.googlesource.com/910123 Reviewed-by: Nektarios Paisios <nektar@chromium.org> Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#535734} [modify] https://crrev.com/7dc3a173d256cf3edbca00d8ca2680a4e4b32a97/content/browser/accessibility/dump_accessibility_tree_browsertest.cc [add] https://crrev.com/7dc3a173d256cf3edbca00d8ca2680a4e4b32a97/content/test/data/accessibility/html/add-click-listener-expected-blink.txt [add] https://crrev.com/7dc3a173d256cf3edbca00d8ca2680a4e4b32a97/content/test/data/accessibility/html/add-click-listener.html [modify] https://crrev.com/7dc3a173d256cf3edbca00d8ca2680a4e4b32a97/third_party/WebKit/Source/modules/accessibility/AXObject.cpp [modify] https://crrev.com/7dc3a173d256cf3edbca00d8ca2680a4e4b32a97/third_party/WebKit/Source/modules/accessibility/AXObject.h
,
Feb 12 2018
Please verify
,
Feb 12 2018
,
Feb 14 2018
,
Feb 14 2018
This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 14 2018
,
Feb 14 2018
Pls merge your change to M65 branch 3325 ASAP so we can pick it up for next Beta release. Thank you.
,
Feb 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3390c604ea990b54d6000c16de59c85e7ea7e0ce commit 3390c604ea990b54d6000c16de59c85e7ea7e0ce Author: Dominic Mazzoni <dmazzoni@chromium.org> Date: Thu Feb 15 18:43:46 2018 Merge to M65: Fix critical accessibility bug causing page content to be inaccessible In Blink accessibility, when an AXObject is "ignored", it's not included in the accessibility tree. The ignored node's parent includes the ignored node's children directly, leaving it out of the tree. As an example, consider this html: <html><body><div><button/></div></body></html> The current heuristics leave the body element out of the accessibility tree. The accessibility tree looks like: rootWebArea (the html node) genericContainer (the div) button There are many ways for a node that's ignored to become unignored, like adding an id or an ARIA attribute. Typically this fires the right notifications and the node gets spliced into the accessibility tree. The bug in this case is that adding a click listener to an ignored node causes it to be not ignored anymore, but it does not correctly invalidate its parent. In the example above, adding a click listener to the body and then modifying the html element "breaks" the tree. The HTML node thinks its child is the DIV, but the DIV thinks its parent is the BODY. This inconsistency breaks the entire page's accessibility tree. The fix is to catch changes to a node's ignored state and call ChildrenChanged. Bug: 797695 Change-Id: Ib8b077e3ebb96ec1634a847db7477589cde74012 Reviewed-on: https://chromium-review.googlesource.com/910123 Reviewed-by: Nektarios Paisios <nektar@chromium.org> Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#535734}(cherry picked from commit 7dc3a173d256cf3edbca00d8ca2680a4e4b32a97) TBR: nektar@chromium.org Reviewed-on: https://chromium-review.googlesource.com/922561 Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/branch-heads/3325@{#476} Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369} [modify] https://crrev.com/3390c604ea990b54d6000c16de59c85e7ea7e0ce/content/browser/accessibility/dump_accessibility_tree_browsertest.cc [add] https://crrev.com/3390c604ea990b54d6000c16de59c85e7ea7e0ce/content/test/data/accessibility/html/add-click-listener-expected-blink.txt [add] https://crrev.com/3390c604ea990b54d6000c16de59c85e7ea7e0ce/content/test/data/accessibility/html/add-click-listener.html [modify] https://crrev.com/3390c604ea990b54d6000c16de59c85e7ea7e0ce/third_party/WebKit/Source/modules/accessibility/AXObject.cpp [modify] https://crrev.com/3390c604ea990b54d6000c16de59c85e7ea7e0ce/third_party/WebKit/Source/modules/accessibility/AXObject.h
,
Mar 13 2018
Issue 812786 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Dec 27 2017Labels: Needs-Triage-M63