Support terminal link keyboard navigation

[Tyriar]

Right now there is navigation mode which is similar to this but only with the text in the line. Where this gets really interesting is navigating types of links (eg. web links only, local files only, all links). Example mockup:

It could feature up, down, left, right as well as previous and next navigation.

[Tyriar]

Idea: Show the hover while navigating the link with the keyboard so you can still see what will happen:

[Tyriar]

Another idea: Announce to screen readers how many rows were travelled.

[zersiax]

Going to admit, I have no idea what exactly you are trying to do here :) Can you, or anyone else, tell me:

• What problem are we solving?
• What is the currently proposed solution?

Thanks :)

[Tyriar]

@zersiax sorry, you're too quick 😃 I'll post a better summary of the problem soon, followed by a proposal.

[Tyriar]

Ok so here's the problem:

Links in the terminal have never been accessible, this is a feature where hovering your mouse over web links or local links that we've detected (eg. ./README.md, foo/bar.md, /foo/bar, etc.) allow you to ctrl/cmd+click them to open the link either in the editor or a browser.

In 1.45 this system has overgone a major overhaul and now features:

• Link detection logic shared with the editor, meaning better web link detection, file:// link support, better unicode support, etc.
• Folders are now supported, opening the explorer when the file is within the workspace or opening a new VS Code window if it's outside.
• A new "word link" concept linkifies basically everything else based on the terminal.integrated.wordSeparators setting and searches the workspace for it. Using this will open the file if the workspace contains exactly 1 matching file, otherwise it will open quick access, basically a shortcut for ctrl+p and typing out the link text.
• A new hover when you mouse over the link that describes exactly what will happen, rather than just "Follow link" as it was before.

The problem is about how to make this keyboard and screen reader accessible.

[zersiax]

Ok ...so this is actually a difficult one :)

Some ideas:

• My thinking is that , when a link gets detected like that, some CSS is triggered to indicate this is a link visually. That tells me there's a hook that triggers that CSS to apear, which we can use. My thought is that for folder links, file links etc in the terminal, we can either wrap the text in a tag, or give it role="button" or role="link" to make it clickable. That would mean that a screen reader user will have to hop into browse mode to find these, but I don't think that can be helped in this case.
• An alternative is to make a hotkey that cycles between the links found in the currently visible output, back and forward, and another one to activate the currently selected link in that cycling list. This is similar to how the VoiceOver rotor actions work on iOS.
• As for the word link ... we need to do something else here. In this sccenario, the user is in the editor (for the most part) and therefore shouldn't be in browse mode. My thinking is to create an alternative that triggers the word-linking feature using a hotkey, taking as input the currently highlighted text in the editor.
  Does that cover everything?

@isidorn , perhaps @MarcoZehe , thoughts?

[Tyriar]

I was writing this up before I knew @zersiax posted, I'll read that now and follow up on it.

---

Now on the solution:

For keyboard accessibility I had the idea of there being a generic command to navigate the terminal buffer based on the link type, say workbench.action.terminal.previousLink and workbench.action.terminal.nextLink. When these commands are used without arguments, it would just navigate up and down the buffer finding any type of link, but I would also like to enable the ability of navigating based on the "link provider" type (word, web, file mentioned above). So take this keybinding as an example that could be build in:

{
    "key": "ctrl+[",
    "command": "workbench.action.terminal.previousLink",
    "when": "terminalFocus",
    "args": { "type": "web" }
}

Triggering this would navigate up to the closest link detected by the weblink provider. Meaning you could run jekyll serve, npm start, etc. and then hit ctrl+[ and enter to launch the browser. This idea will be refined, for example maybe regex would be better than link type, but that's the basic idea. While focused the hover would be visible so you would know visually what is going to happen.

On the screen reader accessibility side, at the time the user presses ctrl+[, the terminal would create an <a> tag to focus. When focused my thinking is it would read out what will happen as in the hover, something like "https://microsoft.com, follow link" or "package.json, search workspace".

You might be thinking that we also have navigation mode in the terminal and while it seems like it would be relatively easy on our side to inject the links there as well, I worry that it would be too spammy as almost everything in the terminal is a link now and it would make it difficult to both navigate to the link you're after while at the same time making it harder to read line output which is the main point of navigation mode. Perhaps this could work but just include web and file links in navigation mode?

Something also to consider is that these links will eventually be extensible by extensions (#91290) so there will be more than just web and file links appearing. Some examples: git commits/branches linking to github, localhost links opening debug browsers.