Say all stops every 10th line in editors with NVDA

[Neurrone]

• VSCode Version: Code - Insiders 1.20.0-insider (2bab83a, 2018-01-10T05:13:51.946Z)
• OS Version: Windows_NT x64 10.0.15063
• NVDA Version: master-14774,0d94f5dd
• Extensions (4)

  Extension	Author (truncated)	Version
  vscode-markdownlint	Dav	0.12.1
  vscode-rust	kal	0.4.2
  rust	rus	0.3.2
  markdown-preview-enhanced	shd	0.3.2

Steps to reproduce:

1. Start NVDA. Create an empty file with the following content:

# heading 1

This is a paragraph
of some text
and some more text.

## heading level 2

* item 1
* item 2
* item 3

2. Perform a "say all" by pressing insert + down arrow (if NVDA is using a desktop keyboard layout which is the default) or caps lock + a if using laptop keyboard layout when your cursor is anywhere on lines 1-10 (the second-last line "* item 2")

Expected behaviour

This should cause NVDA to start reading downwards from the current position to the end of the document.

Actual behaviour

NVDA does start reading from the current position, but stops once it reads line 10 when you start reading from lines <= 10.

I remember reading that VS Code's worked with screen readers based on "paging the text". I'm not sure what that means, could this be a side effect?

Impact

Reading through long files always stops on every 10th line, which is most noticeable when proofreading long files e.g .md or .tex files.

[dranov]

This affects all Monaco editors, not just VSCode.

IAccessible.Value always gets set to the 10 line block that includes the focused line (e.g. if line 11 is focused, the value is lines 11-20, or if line 8 is focused, the text is lines 1-10).

Bonus: if this issue is fixed (such that IAccessible.Value includes the full document text), it would be possible to implement an NVDA app module (app-specific addon) to speak the current line number. (See #52429.)

[dranov]

I remember reading that VS Code's worked with screen readers based on "paging the text". I'm not sure what that means, could this be a side effect?

Background on this: #26730

Relevant lines in the code: textAreaHandler.ts:226 and textAreaState.ts:230

---

The Chromium performance issue which motivated introducing text paging in the first place seems to still exist. Details here (marked fixed, but I can still reproduce on latest Chromium) and here (submitted by @alexandrudima).

I removed the paging limit on a local VSCode build, but this makes the editor unresponsive even with relatively small files (~1000 lines). Until the underlying Chromium issue is fixed, I don't see any way around this.

[dranov]

I've (re-)reported the underlying issue to the Chromium bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=868830

[Neurrone]

Thanks @dranov. Based on the Chromium ticket, it should hopefully be fixed soon.

[dranov]

Update from the Chromium ticket:

1. There is a performance issue related to text metrics ('Enables support for querying line breaks and the bounding box of arbitrary character ranges'). I believe this is what @alexandrudima originally reported and what motivated the introduction of text paging to VSCode. This has not been fixed.

2. Separate from this, there was a recent regression (4 weeks ago) in <textarea> scrolling performance when accessibility support is turned on. This regression, which has only affected pre-release versions of Chromium, has been rolled back (and won't affect Chrome 69 stable, due to be released September 4th), but is completely orthogonal to the VSCode issue.

To recap: we've prevented a performance regression from making it into Chrome stable, but the issue which affected VSCode is still there.

I've reported steps to reproduce the underlying issue (which I've also reproduced on Chromium 61.0.3163.0, the version which VSCode uses internally), so hopefully it will get some attention now.

[dranov]

Good news! The text metrics performance issue is now fixed in Chromium. The relevant commit is here. It might take a few months until the fix makes it into Chromium stable and then Electron.

@alexandrudima, is there some way to run VSCode with a particular version of Chromium, so we can make sure this fixed the issue and text paging can now be removed?

[alexdima]

@dranov There is no easy way to run VSCode, as that requires that there exists an Electron version containing that Chromium version. The closest way to try this would be to run the monaco editor from sources (same source as VS Code)

https://github.com/Microsoft/monaco-editor/blob/master/CONTRIBUTING.md#running-the-editor-from-source

[dranov]

@alexandrudima, I've just tried it on a local build with text paging removed, and the Chromium fix definitely seems to improve things for Monaco as well.

On Chromium 61.0.3163.0 (currently used by VS Code), the editor becomes visibly slow on files ~1k lines long. By contrast, Chromium 70.0.3530.0 starts showing similar slowness at ~10k lines. It does handle larger files (e.g. BigHTML in the Monaco tests, 24k lines), but at that point it's annoying to use.

It's not ideal, but it might be good enough.

[alexdima]

@dranov Thank you for testing this! Once we update to a Chromium version >= 70.0.3530.0, we can raise the limits by an order of magnitude.

I should also test if the current limits (10 lines per page, 500 chars before or after the selection) still make sense. Those were put it back when we used an older version, and perhaps we can raise them even on Chromium 61. Would you be willing to look into this and submit a PR to raise the limits?

[dranov]

Sure, I'll take a closer look at this and submit a PR 😃

Also, considering the issue here ("reading through long files always stops on every 10th line"), besides increasing the current limits, it might be worth it to change the text paging strategy as well. The problem with the current strategy is that, even if you increase the limit to e.g. 100, if you are on line 100 in a larger file and ask NVDA to read until the end, NVDA will just read the current line and stop. Centring the page around the currently selected line might be better. @Neurrone, thoughts?

I'll also try to understand how the Chromium accessibility stuff works -- it seems fundamentally slow, even when text metrics is turned off.

[alexdima]

@dranov Last time I tried with NVDA on Windows, centering the page around the current selection does not work, as it confuses screen readers terribly. For example, on every arrow down you end up removing the first line of text and adding a new line at the bottom. having an arrow key result in a text change causes terrible confusion to the screen reader which then fails to read out the line.

[dranov]

I haven't had the chance to explore this in more depth yet (e.g. understand what's the root cause of the slowness in Chromium or figure out whether it's worth to hack NVDA to understand paging), but I'll dedicate some time for it next week and try to submit a PR.

[Neurrone]

CC @jcsteh could you chime in on how NVDA implements paging for editables?

[isidorn]

We are currently using Chrome 69.
Assigning to myself to look into this once we do the next electron update and start using chrome 70.

Our progress on electron 6.0 adoption can be found here #75802
Once we merge that in we can look into removing the limits @alexandrudima mentions
@alexandrudima can you maybe provide a code pointer?

[alexdima]

@isidorn Here is the code that determines what contents should be placed in the textarea.

vscode/src/vs/editor/browser/controller/textAreaHandler.ts

Lines 203 to 233 in 496d065

	getScreenReaderContent: (currentState: TextAreaState): TextAreaState => {
	if (browser.isIPad) {
	// Do not place anything in the textarea for the iPad
	return TextAreaState.EMPTY;
	}
	if (this._accessibilitySupport === AccessibilitySupport.Disabled) {
	// We know for a fact that a screen reader is not attached
	// On OSX, we write the character before the cursor to allow for "long-press" composition
	// Also on OSX, we write the word before the cursor to allow for the Accessibility Keyboard to give good hints
	if (platform.isMacintosh) {
	const selection = this._selections[0];
	if (selection.isEmpty()) {
	const position = selection.getStartPosition();
	let textBefore = this._getWordBeforePosition(position);
	if (textBefore.length === 0) {
	textBefore = this._getCharacterBeforePosition(position);
	}
	if (textBefore.length > 0) {
	return new TextAreaState(textBefore, textBefore.length, textBefore.length, position, position);
	}
	}
	}
	return TextAreaState.EMPTY;
	}
	return PagedScreenReaderStrategy.fromEditorSelection(currentState, simpleModel, this._selections[0], this._accessibilitySupport === AccessibilitySupport.Unknown);
	},

But we should really test this, because even if Chromium has improved in terms of textarea performance by one magnitude, today they run fine with ~10 lines, maybe they will run fine with ~100 lines... In other words, we should test with super duper large files before removing the limits completely.

[isidorn]

@alexandrudima thanks for the pointer. Yes, we can test it thouroughly once we adopt Electron 6.0..
What I find weird is that this issue is still open https://bugs.chromium.org/p/chromium/issues/detail?id=580955
While this one is closed https://bugs.chromium.org/p/chromium/issues/detail?id=875344

[isidorn]

We did not yet upgrade to Electron 6.0, thus pushing to next milestone.

[isidorn]

We will probably ship electron 6 in October, thus I will look into this in November once I am back from vacation.
As @alexandrudima suggested If this still does not work, we can make this length of the content configurable so that users can easily change this. The downside would be the performance.

[isidorn]

TLDR: set "editor.accessibilityPageSize": 1000 in settings as a workound;

I just verified that the latest Chrome that we use still has the issue. And this is expected since https://bugs.chromium.org/p/chromium/issues/detail?id=580955 is still open.

As a workaround we have introduced the following setting
editor.accessibilityPageSize as the description of the setting says
" Controls the number of lines in the editor that can be read out by a screen reader. Warning: this has a performance implication for numbers larger than the default."

So anyone hitting this issue is advised to increase that setting to a larger number (default is 10). For example 1000 works just fine on my machine.

@alexandrudima and me will measure if we can change the default value, to no longer be 10 but 100 for example.

I am also thinking of having a heuristic to dynamically increase this setting to 100 if we detect a screen reader.

Feedback on the setting name and anything else is very welcome.

[Neurrone]

The setting name sounds fine, and I feel that 100 should be a safe default. This should be documented in the accessibility documentation for users with machines that can take a higher value, for example 1000.

[isidorn]

Thanks for feedback. I have added it to our Accessibility docs so users are aware of this.
As for changing the default we are open for this, however we will first measure. For this I have created this issue #85833
Since this issue is now only depending on the Chrome issue I am marking this as upstream as moving to the backlog.

[isidorn]

Please note that we have changed the accessibilityPageSize behavior. If the screen reader is detected we change the default value to be 1000. More details here #89173

This should provide a better out of the box experience. And due to that I plan to remove the tip from our accessibility docs that users need to configure this setting.

[isidorn]

This is the actual upstream issue https://bugs.chromium.org/p/chromium/issues/detail?id=1001591&q=10000%20chars&can=2

[mltony]

@isidorn, on that chromium issue page someone has commented that it is allegedly fixed now. Would this imply that when new version of chromium is included into vscode, we'd be able to set editor.accessibilityPageSize to infinity?

[isidorn]

@mltony in theory yes. In practice no since Chrome still has performance issues with large textArea. Once that get's fixed we will deprecate pageSize setting and always put the whole content of the editor.
@joanmarie might know more about the chrome performance issue

[joanmarie]

The performance issue is filed here: https://bugs.chromium.org/p/chromium/issues/detail?id=1076525

In comment 1 put where the problem/crazy-lag/timeout is happening. But we're going to need someone with AXPosition smarts to fix it. (My hopes that this was a simple problem were dashed.)

[isidorn]

This should work much better in the vscode insiders starting from Friday.
Since Electron which we use uses Chrome which has fixes in this areas we have decide dto change the editor.accessibilityPageSize to 2000 once a screen reader is detected.
However the bug that Joan Marie filled in Chrome still exists https://bugs.chromium.org/p/chromium/issues/detail?id=1076525

So let me know if you see performance degradation starting from Friday. Thanks

[cannona]

@isidorn Unfortunately, since this change was made, I am seeing a lot of lag when moving around the editor with arrow keys in large files (several hundred lines) while running the latest version of Jaws. We're talking about a good quarter second before Jaws speaks the active character. Setting editor.accessibilityPageSize to 100 resolves the issue.

I was also able to reproduce this issue in NVDA, though it is a shorter lag.

Interestingly, I don't notice the lag when navigating near the top of the file; it seems to get worse the further one moves down the file.

[isidorn]

@cannona thanks for letting us know.
Maybe I was too optimistic with setting a default accessibilityPageSize to 1000 since there is still the issue https://bugs.chromium.org/p/chromium/issues/detail?id=1076525

Let me reduce that to 500. Hopefully that works out better in practice...