Skip to content

Accessibility: NVDA reading wrong or duplicate content in editor #26730

Closed
Closed
Accessibility: NVDA reading wrong or duplicate content in editor#26730
Assignees
alexdima
Labels
accessibilityKeyboard, mouse, ARIA, vision, screen readers (non-specific) issuesbugIssue identified by VS Code Team member as probable bugverifiedVerification succeeded
Milestone
May 2017

Description

@zersiax
Florian Beijers (zersiax)
opened on May 16, 2017
  • VSCode Version: Latest Insider
  • OS Version: OS build 15063

Steps to Reproduce:

  1. Open a file with code in it, the type does not matter.
  2. Arrow through the file at a rate of about twice per second, while NVDA is running.

Observed Behavior:
Rather than speaking the focused line, NVDA will at times read the line or even several lines above it.
Interestingly, braille output appears to work well enough.

Expected Behavior:
NVDA should speak the correct line when navigating through code, for a lot of people using screen readers do not use braille displays to compensate.

Suspected cause:
The fact that braille works well and speech does not leads me to believe it takes too long for the focused line to be visible for NVDA. I don't know enough about the VS Code internals to comment further.

Activity

  1. ImageDaniel Imms (Tyriar)
    added
    accessibilityKeyboard, mouse, ARIA, vision, screen readers (non-specific) issues
    editor
    on May 16, 2017
  2. ImageDaniel Imms (Tyriar)
    assigned
    Alexandru Dima (alexdima)
    on May 16, 2017
  3. ImageAlexandru Dima (alexdima)
    added this to the On Deck milestone on May 17, 2017

  4. Neurrone commented on May 19, 2017

    @Neurrone
    Dickson Tan (Neurrone)
    on May 19, 2017

    I can reproduce this on the latest stable as well with NVDA.

  5. zersiax commented on May 21, 2017

    @zersiax
    Florian Beijers (zersiax)
    on May 21, 2017
    Author

    I have heard from several NVDA users getting hit by this, some going as far as saying this bug renders the IDE impossible to use effectively

  6. Neurrone commented on May 21, 2017

    @Neurrone
    Dickson Tan (Neurrone)
    on May 21, 2017

    Florian Beijers (@zersiax) yes, its impossible to use, notepad would be better because of this bug.

    Its like having the screen not displaying lines as they properly appear in the file.

  7. alexdima commented on May 21, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on May 21, 2017
    Member

    The editor text accessibility is implemented by using a textarea (the same one we use for input events), where we mirror the buffer text and the selection. Until last month (when we updated to a newer Electron version), it was not possible for us to discern if a screen reader is attached or not, so at this point we always do the following:

    • the textarea only gets a "page" of the buffer. e.g. if the cursor is in lines 1-10, only lines 1-10 are placed in the textarea. If the cursor is in lines 11-20, only lines 11-20 are placed in the textarea. We are doing this because when opening large files (more than 1 MB), Chromium stalls for seconds if we write large quantities of text to the textarea. This might be a cause of confusion for screen readers when going from line 10 to line 11, for example, where all of a sudden we move to the next page.

    • we write to the textarea with the same code path that we paint the lines, i.e. at the next browser animation frame (i.e. not synchronously in the handling of the keyboard event). If two key presses occur before Chromium calls us back it is possible we will update the textarea only once. This might also be a cause of confusion for screen readers.

    I will investigate to adopt the new available Electron API to detect when a screen reader is attached and attempt to remove these two possible causes.

  8. Neurrone commented on May 21, 2017

    @Neurrone
    Dickson Tan (Neurrone)
    on May 21, 2017

    alexandrudima thanks. Probably a stupid question, but aren't there standard html controls that can be used for multi-line edits?

  9. alexdima commented on May 21, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on May 21, 2017
    Member

    Dickson Tan (@Neurrone) The standard html control that is used for multi-line text is a <textarea>.

  10. alexdima commented on May 21, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on May 21, 2017
    Member

    I can confirm and reproduce the problem even in a file with 10 lines (i.e. the "paging" does not appear to be the root cause):

    • I create a file with 10 lines, with the content:
    Line 1
Line 2
Line 3
Line 4
Line 5
Line 6
Line 7
Line 8
Line 9
Line 10
    • I place the cursor at the beginning of the file and I press arrow down 9 times
    • Sometimes, the same line is pronounced multiple times by NVDA. e.g. of pronounced text:
    Line 1
Line 1
Line 2
Line 3
Line 5
Line 5
Line 6
Line 8
Line 9

    I'll try next a change where we call setSelectionRange in the <textarea> synchronously from the keyboard event handler (instead of from the animation frame).

  11. ImageAlexandru Dima (alexdima)
    added
    bugIssue identified by VS Code Team member as probable bug
    on May 21, 2017

  12. alexdima commented on May 21, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on May 21, 2017
    Member

    Unfortunately, calling setSelectionRange synchronously from the keyboard event handler makes no difference.

  13. alexdima commented on May 21, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on May 21, 2017
    Member

    Also, this is something I can reproduce on Chrome v58 (via the standalone editor running from master and via the standalone editor from January at https://microsoft.github.io/monaco-editor/)

  14. Neurrone commented on May 21, 2017

    @Neurrone
    Dickson Tan (Neurrone)
    on May 21, 2017

    James Teh (@jcsteh) any ideas?

  15. 32 remaining items

  16. ImageDirk Bäumer (dbaeumer)
    added a commit that references this issue on May 26, 2017

    a18y: avoid duplicate events when navigating trees (for #26730)

    03284d8

  17. Neurrone commented on May 26, 2017

    @Neurrone
    Dickson Tan (Neurrone)
    on May 26, 2017

    James Teh (@jcsteh) perhaps the version of VS code I'm using (latest stable) uses an older version of chrome?

  18. alexdima commented on May 31, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on May 31, 2017
    Member

    Since this is becoming an uber-issue, let me try to sum up and split it into other issues where necessary:

    Issue from Florian Beijers (@zersiax) : Navigating with cursor keys in the editor results in NVDA reading the same character or the same line twice

    Changes on our side: we have done a full review of all the stuff (stepping through the ~25 listeners) that executes in the cursor movement case and have reduced the time spent in our code to ~1-2ms. As part of this 2ms we also immediately move the cursor in the <textarea> such that Chromium will emit a cursor position change accessibility event sooner, not at the next animation frame. These ~2ms spent on our side sometimes result in the event being emitted within the 30ms NVDA timeout, sometimes not, but this is outside of our control.

    Solution: The plugin provided by Derek Riemer (@derekriemer) that increases NVDA's timeout to 200ms seems to completely resolve the issue. Furthermore, thanks to James Teh (@jcsteh) there is an open PR in NVDA where the default timeout is increased from 30ms to 100ms.

    Issue from Florian Beijers (@zersiax) : Navigating with the cursor keys in the explorer tree results in too many accessibility events and too many items are read

    Solution: Benjamin Pasero (@bpasero) has pushed a fix where the aria labels on tree elements are no longer modified in the selection change case.

    Issues from Dickson Tan (@Neurrone) :

    Arrow down in word wrapped editor ends reading the entire line possibly multiple times: extracted to #27766 - I can reproduce

    Up/Down arrow in a read only editor sometimes moves you outside the editor #27765 - I still need to reproduce and confirm.

    I think those 4 issues sum up this thread, since we continue the issues from Dickson Tan (@Neurrone) in two separate threads, I propose to close this one and celebrate our progress. ❤️

    Derek Riemer (@derekriemer) One last ask: Would it be possible for you to host the plugin that increases the timeout to 200ms on GitHub or something similar. I would like to document that we recommend folks install this plugin when working with NVDA and VS Code and I would like to link to it from our website and from our release notes. I wouldn't want this to end up causing too much traffic costs or something... Thank you !

  19. ImageAlexandru Dima (alexdima)
    closed this as completedon May 31, 2017
  20. ImageAlexandru Dima (alexdima)
    unassigned
    João Moreno (joaomoreno)
    on May 31, 2017

  21. derekriemer commented on May 31, 2017

    @derekriemer
    Derek Riemer (derekriemer)
    on May 31, 2017 via email

  22. alexdima commented on Jun 1, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on Jun 1, 2017
    Member

    Derek Riemer (@derekriemer) That would be great! Another comment here would work great ❤️.

  23. Neurrone commented on Jun 4, 2017

    @Neurrone
    Dickson Tan (Neurrone)
    on Jun 4, 2017

    Using the latest insider build and the add-on, am experiencing inaccurate reporting of the current word when moving by word using ctrl+right/left arrow. Still see this issue as well with up/down arrows, also by character.

    Are the changes made on VS Code's end not included in the insiders build yet?

  24. Imageroblourens
    added
    verifiedVerification succeeded
    on Jun 5, 2017

  25. alexdima commented on Jun 6, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on Jun 6, 2017
    Member

    Dickson Tan (@Neurrone) The latest insiders contains all the relevant changes. Let's start a new thread/issue with your detailed setup. Could you please include:

    • do you have any other installed NVDA add-ons that might interfere? (I don't have sufficient knowledge on this side to tell if there might be some interference going on)
    • do you experience this on a particular file, or on all files (even small files)?
    • do you experience this around selecting large blocks of text or simply around pressing the arrow keys?
    • what does Alt+F1 report when you encounter this problem?

  26. Neurrone commented on Jun 8, 2017

    @Neurrone
    Dickson Tan (Neurrone)
    on Jun 8, 2017

    I've restarted NVDA with all add-ons disabled and am still encountering this. I'm experimenting with the read-only settings file and the user settings file.

    Am just pressing the left/right arrow keys (arrows, ctrl + left/right arrow to move by word, etc). Notice this especially when you go right/left, then change direction.

    Not sure what alt+f1 says, since i can't find the message with NVDA.

  27. bramd commented on Jun 8, 2017

    @bramd
    Bram Duvigneau (bramd)
    on Jun 8, 2017 via email

  28. alexdima commented on Jun 9, 2017

    @alexdima
    Alexandru Dima (alexdima)
    on Jun 9, 2017
    Member

    Dickson Tan (@Neurrone) Let's continue in a fresh issue, #28306.
    Bram Duvigneau (@bramd) I have extracted your comment to #28308.

  29. derekriemer commented on Sep 3, 2017

    @derekriemer
    Derek Riemer (derekriemer)
    on Sep 3, 2017

    Hi: Sorry, I never published the plugin. As of the last NVDA version (2017.3), it now has a cursor timeout of 100 MS.

  30. Imagevscodebot
    locked and limited conversation to collaborators on Nov 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

accessibilityKeyboard, mouse, ARIA, vision, screen readers (non-specific) issuesbugIssue identified by VS Code Team member as probable bugverifiedVerification succeeded

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions