Code navigation accessibility: Support tab-driven keyboard navigation

[umpox]

Related RFC

Description

We should allow tabbing through interactive elements in the blob view.

Acceptance criteria:

• All possible ranges of code intelligence (through stencil) on load, and converted into buttons
• These buttons should be focusable (this should be the default behavior)
• Clicking (or pressing enter) on one of these buttons should trigger the code intel hover overlays
• It should be possible to easily interact with the hover overlays without losing tab position
• The blob should be focused on load, or if a relevant action is clicked (e.g. file in sidebar)
• If the blob is loaded against a specific line, focus should be driven to that line, so tabbing will move the user to a relevant part of the blob.
• If the blob is loaded against a specific range, focus should be driven to that range. If that is not a valid button, focus should go to the nearest line at the top of the range.

Implementation

1. Fetch ranges using stencil on load.
2. Iterate through blob view and convert ranges into buttons, with relevant onClick/focus/etc handlers
3. WIP PR here: https://github.com/sourcegraph/sourcegraph/pull/41935

/cc @felixfbecker

[felixfbecker]

https://github.com/sourcegraph/sourcegraph/issues/36567 was closed in favor of this, does this issue also cover opening the tooltip with the keyboard? For screen readers, the <a> links would probably need aria-haspopup="dialog" to declare that there is a popover available.

[felixfbecker]

converted into buttons

Shouldn't they be links (<a> elements) rather than buttons? Currently, when clicking on them, they navigate to a different URL, which semantically makes them links. That would also add the ability to open in new tabs, see the target URL on hover, etc

[umpox]

@felixfbecker The only constraint right now is that we can fetch ranges through the stencil API, but we cannot fetch the definition information available to know if these should link directly to it, rather than open the references panel. That information is quite slow to fetch, so it's tricky to do this before a user might be ready to "click" the token.

Some solutions that I've been thinking about:

1. Improve the bulk ranges query so that it's faster, and fetch information for ranges within the current viewport. Should mean in most cases we have information readily available. This is one thing that Eric mentioned doing (see Slack context below).
2. Keep everything as a link that just opens the panel at the current range. Fetch definition information on focus, and if that's available then we just update the link. AFAIK this is similar to how the current hover logic works. Unsure how screen readers will adapt to that (will they read out the new URL?). We'll also need to move hover information into the panel for this behaviour, as this would skip the overlay completely.

Additional context from Slack

@efritz
Cesar and I are about to switch over from LSIF to SCIP so we’ll have some benefits in performance there. We can design a new bulk-load query that will replace Ranges.
The current ranges query is pretty underpowered - it won’t do anything with cross-index/cross-file results and only shows results within the same blob.
This was was originally only meant to power quick local navigation and document hovers.
Stencil might work better; it gives all the ranges but no data about it. You know where all the tokens are that can be navigated but will still require an additional request on interaction.
Would be great to know exactly what API you would like to use given an infinite budget. We can use that to inform how exactly we change our API surface to support other teams.

@umpox
Right now we want to mimic the keyboard navigation you get on Google CS (e.g. load this, and press the tab key a few times, probably only works in Chrome).
In a perfect world we would have the ranges and hover/definitions information available immediately on load, so we also don’t have to worry about fetching anything on hover. Essentially these tokens would already be a button or link when the page is loaded, and clicking them would immediately go to definition/load the references panel rather than having to wait to fetch that information first

@efritz
Awesome. I think it’s probably going to be a bit before we efficiently get all cross repo results online at load for an entire document, but…
What if we kept a stencil like call that gives you everything where data is and then you have to make ranged calls like give me deep information for all stencils in this viewport.
That way it’s not an unbounded cost upfront, and we can only resolve what the user can interact with (also allows you to pre load results for viewports the user is near).
The difference between us and Google CS is that they are allowed to do a full analysis on their entire corpus at once. We have to deal with results that are constantly changing and have to move a bit of that complexity into query time as a result.