Add symbol provider for terminal accessible buffer

[meganrogge]

Right now, we present only the command, the exit code if non-zero, and the output.

Some questions:

• is presenting ...exited with code # useful?
• should we add the cwd
• should we include the prompt

cc @jooyoungseo for any thoughts

[jooyoungseo]

The recently introduced heading semantics in the accessible terminal buffer does not seem to live up to our expectation because the screen readers' vague support for "document" role landmark. In theory, "document" role would work like a web page and will auto-activate screen readers' virtual cursor (AKA, browse mode). Tagging each command with heading semantics, thus, would make sense. Unfortunately, most major screen readers do not seem to properly support "document" role, which introduces some side effects against heading semantics defined within the document role. For example, NVDA seems to behave like a document mode instead of browse mode against "document" role and it does not properly recognize heading semantics in the terminal buffer unless you explicitly switch to browse mode. JAWS is even worse... I did not have a chance to file a new issue regarding this, but I will demonstrate this when we meet soon.

[meganrogge]

Okay thank you for that insight. I recall you said the output container is very accessible. I will see what we do there.

[meganrogge]

explored using role: presentation and using the arrow keys to navigate line by line on this branch https://github.com/microsoft/vscode/tree/merogge/role-presentation

because that's what we do for the output view. works with VoiceOver, but not with NVDA.

[jooyoungseo]

@meganrogge -- The ideal model that I refered to previously was Ctrl+Shift+U (Tasks Output) and it has a textbox role.

[meganrogge]

@Tyriar and I had a look at the output together and noticed that it is a monaco editor. We will see what the overhead is of inserting that in the terminal

[meganrogge]

It looks like the monaco editor will work.

We can use this issue to track also the possibility of adding a language/symbol provider so that landmarks such as commands and output can be navigated to separately. We could also use the editor quick fixes to present our terminal quick fixes in an accessible manner.

[jooyoungseo]

@meganrogge Regarding your original questions on symbol provider, I would recommend making the integrated shell outcome as similar as possible to the non-integrated shell results by default. Users may feel confused if they see different styles between enabled and disabled integrated shells.

It would be even more ideal if you could add some settings for users to customize the buffer output by allowing them to toggle on and off for "cwd", "prompt", "command", "non-exit code."

My personal preference would look like the following:

{
  "display.cwd": false,
  "display.prompt": false,
  "display.command": treu,
  "display.non-exit-code": false
}

[meganrogge]

Great idea 👍🏼

[Tyriar]

I think we should present the entire buffer as is in a monaco instance (like a regular editor) and then use symbols to expose the command smarts if shell integration is enabled:

[meganrogge]

I investigated and we'd need to use an EditorPane and either have our own OutlineProvider similar to notebooks or register a terminal language provider. Both seem like overkill and more complicated than what we need.