NVDA doesn't read the status line

[dbaeumer]

Testing https://github.com/microsoft/vscode/issues/96265

All NVDA reads is: No status line found.

[isidorn]

This seems to work for me, the first couple of times that I trigger the "No status line found" is read. However afterwards I get the status bar nicely read.

fyi @leonardder might there be an issue on the NVDA side for status bar not being read.

[MarcoZehe]

I also get the "no status bar" message in current insider builds. I have the S Code root folder open and an .ts file opened in an editor. The status bar is definitely there, I can get to it with F6.

[isidorn]

Ok so it seems like the NVDA can not locate it even though we set a "status" role on it. Not sure what more can we do here. fyi @feerrenrut

[feerrenrut]

I haven't looked into it, but I think the default NVDA implementation just takes a guess at the location of the status bar. See def getStatusBar() in source/api.py. Essentially this code just tries to get the object 1 pixel above the bottom of the window (on the left side). Hit testing can be a little flaky in chrome, so perhaps that accounts for the intermittent success?

It seems likely that a smarter implementation could take over ~in~ while using vsCode, this would likely need to be behavior overridden by an appModule.

[marlon-sousa]

Hello,

Using following version of insiders:

Version: 1.45.0-insider Commit: abb4a35cfc26102f93fd00df7b59ce1a19c2017a Date: 2020-04-28T05:36:25.810Z (8 hrs ago) Electron: 7.2.2 Chrome: 78.0.3904.130 Node.js: 12.8.1 V8: 7.8.279.23-electron.0 OS: Windows_NT x64 10.0.17763

Using NVDA 2019.3.1.

By pressing nvda key + end I can hear status bar information. It would fail if I quickly press that command as soon as VS Code opens, but one second after it is opened I have been able to consistently read updated status bar information without failure.

I can notice failure on first nvda key + end pressed quickly when maximizing or estoring windows, but soon after this fails the next calls report correctly.

From my point of view this first failures are not an issue, they seem to happen when the window is some how redrawing.

Other than this I haven't been able to detect failures.

[isidorn]

Ok thanks for more details. So this seems to be an issue on the NVDA end. @feerrenrut does it makes sense that I open an issue in the NVDA repository. Could you simply look at the HTML tree and look for the object with role = status. Which is what I believe Orca on Linux is doing and @joanmarie can confirm.

[isidorn]

@marlon-sousa yes I get the same behavior as you, after sime time this seems to work fine. Though the instability is due to the hit testing approach of nvda.

[feerrenrut]

@isidorn Yes, I think an issue on NVDA is appropriate, there is certainly something better NVDA could do in this case. However the hit testing inaccuracy in chromium is also an issue that's likely to cause problems in a few situations. From conversations with people working on chrome I believe it's a known issue, though I don't have an issue tracker link handy. My very vague understanding of the problem in Chrome is that in order to calculate the hit test it needs to do an asynchronous render pass, the result is cached meaning subsequent attempts work.

[joanmarie]

Orca is doing an accessibility tree dive from the bottom up, looking for something with the accessible role of "status bar". I recently had to change it to sanity-check candidate status bars for the "showing" and "visible" accessibility states because VSCode has -- or at least used to have -- some offscreen element with ARIA role status and no contents. Orca was finding it first and not bothering to look any further.

@feerrenrut: Yeah, I ran into that Chrome hit-test thing myself in a different context. Orca now asks twice -- at least for the place where the issue came up.

[marlon-sousa]

Even so I would push this to production.

Having it read more than 98% of times is way better than not having it read at all.

[isidorn]

@feerrenrut created https://github.com/nvaccess/nvda/issues/11064 @marlon-sousa yes we will ship this, no worries :)