Issue metadata
Sign in to add a comment
|
Document accessible re-created in some cases |
||||||||||||||||||||||||
Issue descriptionChrome Version: 63.0.3205.0 (Official Build) canary (64-bit) OS: Windows 10 Version 1703 (OS Build 16251.0) 64-bit Steps to reproduce: (1) Start Chrome and the NVDA screen reader. (2) Open this URL: http://www.freedomscientific.com/ (3) Press control+home to move to the top of the document. (4) Press down arrow. Expected: NVDA should say just "link graphic Freedom Scientific" Actual: NVDA does say this, but then proceeds to read the entire page. (5) Press control+home. Expected: NVDA should say just "link Skip to main content" Actual: NVDA does say this, but then proceeds to read the entire page. This occurs because the document accessible is destroyed and re-created every time focus moves to or is removed from the Skip to main content link. The unique id of the document changes each time this occurs. NVDA thus thinks this is a new document and treats it accordingly. This is probably caused by a CSS change, but I don't know specifically what CSS. I understand parts of the tree need to be re-created sometimes. However, the document accessible must *never* be re-created. Otherwise, it will be treated as a new document. Impact: This makes it very difficult/tedious/confusing to use affected pages for NVDA users. Originally reported as NVDA issue: https://github.com/nvaccess/nvda/issues/7391
,
Sep 11 2017
Chrome 63.0.3212.0 (Official Build) canary (64-bit) (cohort: 64-Bit) Windows 10 Enterprise Version 10.0.14393 Build 14393.1593 NVDA 2017.3 JAWS 2018 Beta Firefox 55.0.3 (64-bit) Hello, To add to the last comment, I tried this in other scenarios for comparison. Chrome + NVDA, can repro, both times the entire page is read Firefox + NVDA, cannot repro, reads just the expected text Chrome + JAWS, cannot repro, entirely different issue outside scope of this bug (link Skip to main content is not read)
,
Oct 30 2017
,
Nov 14 2017
,
Dec 8 2017
Another user reported similar behavior: Not exactly sure what is going on however, the behavior I can notice is that the page seems to be flickering or refreshing every few seconds and every time it does so, the cursor focus is placed somewhere else so, linearly navigating is kind of out of question. One example site I can think of where this happens is on www.walmart.com and I cannot repro this issue on other browsers for the same site. Note: I did notice this behavior on other sites but cannot recall which ones at this point.
,
Dec 11 2017
,
Dec 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7d3a2280ccdfb7c1bb1ace857edf678dcf519fdf commit 7d3a2280ccdfb7c1bb1ace857edf678dcf519fdf Author: Nektarios Paisios <nektar@chromium.org> Date: Tue Dec 12 04:21:46 2017 Keep the same tree root when the root is simply updated R=dmazzoni@chromium.org Bug: 785100 , 761882 Change-Id: Iab2181a6208b116eb2043446eb8edb4061a59d76 Tested: Manually with Jaws and NVDA on crbug.com and freedomscientific.com, unit test Reviewed-on: https://chromium-review.googlesource.com/820107 Commit-Queue: Nektarios Paisios <nektar@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#523332} [modify] https://crrev.com/7d3a2280ccdfb7c1bb1ace857edf678dcf519fdf/ui/accessibility/ax_tree.cc [modify] https://crrev.com/7d3a2280ccdfb7c1bb1ace857edf678dcf519fdf/ui/accessibility/ax_tree_unittest.cc
,
Dec 12 2017
,
Dec 12 2017
,
Jan 11 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by pnangunoori@chromium.org
, Sep 5 2017Status: Untriaged (was: Unconfirmed)