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

Issue 725051 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug
Team-Accessibility



Sign in to add a comment

NVDA reads the same character or line twice when using arrow keys in Google Docs

Reported by alex.d...@gmail.com, May 22 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Example URL:
https://docs.google.com

Steps to reproduce the problem:
Hi, I work on Visual Studio Code and I'm trying really hard to build a Screen Reader friendly editor. This is an issue that affects our users and it affects Google's customers too.

Here are two ways to reproduce. They both assume NVDA is running and the NVDA Speech Viewer can be used to verify. I have tested with NVDA_2017.1, but it occurs in older NVDA versions too:

a). Reproducible steps in Google Docs
b). Reproducible steps using a simple <textarea> in a sample html page

a). Reproducible steps in Google Docs
1. Go to docs.google.com and create a new document
2. Set the content to the following text:

Hello world, how are you doing on line 1
Hello world, how are you doing on line 2
Hello world, how are you doing on line 3
Hello world, how are you doing on line 4
Hello world, how are you doing on line 5
Hello world, how are you doing on line 6
Hello world, how are you doing on line 7
Hello world, how are you doing on line 8

3. Enable Accessibility via Shift+Alt+Z .
4. Go to Accessibility > Settings > Enable Braille Support.
5. Place cursor on first line, at the beginning.
6. Press arrow down or arrow right multiple times, in a calm fashion (i.e. press the key + wait for the text to appear in the Speech Viewer).
7. Observe: every now and then, a line is read twice (more rarely) or a character is read twice (more often). e.g.: H, e, e, l, o etc.
8. If you have any trouble reproducing, simply increase the document or the line size.

b). Reproducible steps using a simple <textarea> in a sample html page
1. Open the attached sample that contains a textarea with a small chunk (60KB) of text.
2. Place cursor on first line, at the beginning.
3. Press arrow down or arrow right multiple times, in a calm fashion (i.e. press the key + wait for the text to appear in the Speech Viewer).
4. Observe: every now and then, a line is read twice (more rarely) or a character is read twice (more often).
5. If you have any trouble reproducing, simply increase the length of the text inside the textarea.

The simple <textarea> sample html page works as expected in Firefox.

VS Code issue: https://github.com/Microsoft/vscode/issues/26730

What is the expected behavior?

What went wrong?
See above

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 58.0.3029.110  Channel: stable
OS Version: 10.0
Flash Version:
 
repro.html
62.4 KB View Download
Components: -Blink Blink>Accessibility
I can confirm this happens on multiple machines with multiple versions of NVDA, Chrome and multiple versions of Windows, but with varying amounts of rarity.
Cc: ligim...@chromium.org
Labels: -Pri-2 Needs-Bisect Needs-Triage-M58 Pri-1

Comment 4 by hdodda@chromium.org, May 23 2017

Cc: hdodda@chromium.org
Labels: -Needs-Bisect M-60
Status: Untriaged (was: Unconfirmed)
Tested the issue on windows 10 using chrome M58 #58.0.3029.110 and with NVDA_2017.1 and issue is reproduced.

When arrow keys are used NVDA reads the same character for every other character.

Issue is seen from M54 and before M54 ,the behavior is different .

Marking it as untraiged , to get this addressed by accessibility team.

Thanks!
Labels: triage-dominic
Components: -Blink>Accessibility UI>Accessibility>Compatibility
Labels: -Arch-x86_64 -M-60 -Via-Wizard-Content -Needs-Triage-M58 -triage-dominic
Owner: nek...@chromium.org
Status: Assigned (was: Untriaged)
Labels: triage-dominic
Labels: -triage-dominic

Comment 9 by nek...@chromium.org, Dec 10 2017

Labels: win-a11y
I suspect this is caused by delays in firing accessibility events due to Chrome's multi-process architecture. It would take some creative design on our part and communication with the screen reader vendor to fix.
Marking as higher priority, but it's not an easy bug to tackle.
Status: Available (was: Assigned)
Labels: editing
Labels: a11y-testers
a11y-testers, please try to repro and give recent repro steps and behavior

Status: Verified (was: Available)
Chrome: 66.0.3353.0
NVDA: 2017.4
JAWS: 2018.1802.78

Unable to reproduce this issue. Please file again with updated repro steps if this issue still exists.

I believe this issue has been fixed.
Labels: -a11y-testers

Sign in to add a comment