Vscode: I can't browse links in virtual documents on VSCode using orca

[jvesouza]

Issue Type: Bug

cc: @isidorn

1. Launch orca and VSCode.

1. Press ctrl+shift+x.

2. Type python and wait for the orca to announce that extensions have been found. This takes a little time.

3. Press the tab key and using the arrows locate the python extension, it should be the first.

4. Press the enter key to move the focus to the virtual document that describes the extension.

5. Try using the tab or shift+tab keys to navigate between links.

In my environment links are not advertised by orca. The interesting thing is that if I repeat steps 2, 4, 5 and 6, the tab key seems to work as expected.

I reported this problem in the orca list and received the followin response from @joanmarie:

I can reproduce this problem. It appears that the first time the document is shown, there are no accessibility events when each link gets focus. Thus Orca doesn't know you've moved. The events >start showing up once the document is reloaded. Not sure why. But this looks
like a problem in VSCode or Chromium.

VS Code version: Code - Insiders 1.48.0-insider (731f9c25632dbbf01ee3a7892ad9d2791fe0260c, 2020-07-24T05:43:53.437Z)
OS version: Linux x64 5.7.10-arch1-1

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (4 x 2862)|
|GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
opengl: enabled_on
protected_video_decode: unavailable_off
rasterization: disabled_software
skia_renderer: enabled_on
video_decode: unavailable_off
vulkan: disabled_off
webgl: enabled
webgl2: enabled|
|Load (avg)|1, 1, 1|
|Memory (System)|9.60GB (0.35GB free)|
|Process Argv|-n --no-sandbox --crash-reporter-id 8d5a3738-d241-4b34-b208-057882a7b877|
|Screen Reader|yes|
|VM|0%|
|DESKTOP_SESSION|gnome-xorg|
|XDG_CURRENT_DESKTOP|GNOME|
|XDG_SESSION_DESKTOP|gnome-xorg|
|XDG_SESSION_TYPE|x11|

[isidorn]

@jvesouza thanks for filling this. For me in the Extension Description view pressing tabs goes over "Details", "Feature Contributions", "Changelog" and other extension details. However I agree with you that tab does not navigate over the links in the details of the extension.
However this could be a duplicate of https://github.com/microsoft/vscode/issues/88792

Assigning first to @sandy081 so he decides. So what is missing is for the focus to go over the links in the extension description.

[sandy081]

I think it does go over the links in the extension description after going through all tabs. Order is

-> Extension header.
-> Extension tabs.
-> Content opened in the tab (for eg., if Details is opened, links in the details)

If you open the extension by pressing enter / double click, details tab gets focused and tabbing will go through links in the details tab.

I think the above order makes sense. Let me know if there is something missing?

[github-actions[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[isidorn]

Let's reopen this issue and give more time for @jvesouza to respond

[jvesouza]

First of all I'm sorry for the delay in replying.

The problem still exists in the most current versions of VSCode. When I visit the details of an extension for the first time using orca as a screen reader, I am unable to navigate the links on the details page with the tab key.
I press the tab key and shift + tab but nothing is read by orca.
The curious thing is that if I visit the details of the same extension again without having visited another extension, the tab key works as expected.

The steps are as follows:

1. press ctrl+x and type python.
2. Press the tab key and choose python from the list of extensions.
3. Press the enter key.
4. Try to use the tab key to navigate in the links.

In my environment orca stays mute.

If I immediately repeat the same steps the tab key will work as expected.

[isidorn]

@jvesouza yes I can reproduce what you are hitting.
On Linux - tab nicely moves focus between links but Orca does not read anything. If I do it again then it just works.

On Windows with NVDA I see similar issues - tab does not move focus through links. If I turn off NVDA then Tab nicely moves focus.
So it might not be Orca specific, though it would be great if @joanmarie or @marcozehe have some ideas on what might be the issue. I believe some role transition is causing this strangness.

[joanmarie]

@isidorn: Role transition? Are these links somehow special? My gut tells me that these objects are not in the accessibility tree at the time they initially get focus. But my gut might be wrong. And if it's right it would be helpful to know why so we can fix it in Chromium.

[sandy081]

@isidorn Also assigned this to you because of your expertise here. Please let me know if I have to do any changes to fix here, I would do so.

[isidorn]

@joanmarie those links are only special becuase they are a part of a webview (which might not belong to the same DOM structure as the rest of vscode)
Though @sandy081 and @mjbvz might know more about the webview and how it is used in the Extensions description view.

[sandy081]

@mjbvz might know.

[mjbvz]

Webviews are weird because they are not part of the normal dom flow. This means that we have to use the aria-flowto attribute to try to help screenreaders understand where the webview conceptually slots into the dom

@joanmarie Do other webview based views, such as the markdown preview or release notes work?

[jvesouza]

@mjbvz I can't navigate with the tab key when I open the markdown preview.

I performed the following steps using the README.md file present in the VSCode repository:

1. Launch orca.
2. launch code-insiders using README.md as parameter.
3. After the file is opened press ctrl+shift+v.
4. Try to navigate using the tab key.

In my machine Nothin is read by orca.

But I can read the markdown preview using the arrows.
Also the structure commands like 'h' to jump to the next heading works as expected.

[isidorn]

@jvesouza thanks for trying it out
@mjbvz so it seems to be a general webview issue.

[joanmarie]

@mjbvz: I'm fairly certain that aria-flowto is not very well supported by screen readers. See related https://github.com/w3c/aria/issues/630.

That said, I doubt that is the source of the problem. In the case of Orca -- which does not take over the Tab key -- focus moves as expected but Orca fails to say anything because there is no accessible focus event from the link. But if it's easy to change aria-flowto to aria-owns it might be worth a try to see if things magically start working. (And if they do, it would be great to come up with a stand-alone test case so we can get this fixed in Chromium.

[jvesouza]

This information may be superfluous, but the tab key doesn't work either when I visit the release notes page from the help menu.

[isidorn]

@joanmarie thanks for details.
@mjbvz can you look into using the aria-owns? Or you will not have time this milestone and I should look into it?
@jvesouza yeah that sounds like the same issue

[joanmarie]

In order to see if this is a problem that was potentially already fixed in Chromium, I tried running VSCode with my local build of Chromium loading file.md, loading the preview, and then tabbing to the links. Orca presented the link as expected (i.e. no missing events).

So then I tried the same thing using google chrome stable and unstable. Unfortunately, when I gave the command to load the preview, I got a new page tab but the contents remained empty. Any ideas why that might be?

If the problem is indeed already fixed in Chromium, I could do a bisect to figure out when. But I need to be able to reliably load the previews; if instead what I'm trying is not the same problem, it would be helpful to have some steps to reproduce that I can do in the web browser.

Thanks!

[isidorn]

@joanmarie thanks for trying it out!
Are you running VS Code in the latest Chromium using the
yarn watch-web and yarn web?
Since when I do this I can always open a markdown preview of the file.md. F1 > open markdown preview

[joanmarie]

@isidorn. Yup. Turns out I had to unblock third-party cookies. Silly me for not checking the console. I'll see if I can do a bisect and find a point where links in the markdown preview are broken when VSCode is run in the browser.

[isidorn]

@joanmarie thanks a lot for investigating deeper. Would be great if it turns out to be something we can cherry pick to our electron release.

[joanmarie]

So even using the same revision as is in the VSCode Insiders build, I cannot reproduce the problem when running VSCode in Chromium. The steps to reproduce that I'm using are:

1. Launch Orca
2. Run yarn web
3. Launch chromium and load localhost:8080
4. View file.md
5. Press Ctrl+Shift+V for the preview
6. Press Tab several times to move amongst the links

Orca presents the links each time. I went back as far as 78.0.3902.0 (My VSCode Insiders is 78.0.3904.130).

So....@isidorn can you reproduce this problem when VSCode is run in Chromium? If so, what are your steps to reproduce the problem?

[isidorn]

@joanmarie I can not repro when VS Code is run in Chromium. Sorry for not trying that earlier, in that case it works just fine.

@mjbvz is there a difference between how Webviews work in Browser and VS Code desktop or it is the exact same approach?

[mjbvz]

Webviews in the browser use a normal <iframe>

Webviews on desktop use the <webview> element (which is powered by an iframe but has some unique features as well)

[isidorn]

@mjbvz is it possible to do some code change such that I can force webviews in the browser to use <webview>. Asking becuase that would help us test this against different chrome versions.
Alternative do you have some standalone sample of webviews which can be run in Chrome?

[mjbvz]

Unfortunately I don't think so. Normal browser pages in chrome cannot use <webview> elements are far as I know

Our long term goal is to switch over to using normal <iframes> on desktop as well, but there are a few electron issues blocking this