General keyboard shortcuts

[quinnkeast]

This is the implementation issue for RFC 345: Keyboard navigation in Sourcegraph.

Figma – Keyboard navigation underpinnings audit

Next steps from @felixfbecker:

• Resolve open comments in the RFC, in particular:
  • Alignment with established accessibility concepts (landmark areas and widgets, vs "navigation areas" and "application areas")
• Audit the main screens of the app (blob view, search results). I suggest creating a Figma for this with screenshots we can overlay with rectangles and annotations.
  • Highlight the landmark areas and which keyboard shortcuts we want to use for jumping to them.
  • Highlight widgets that currently do not have standard keyboard controls (e.g. file tree, revision selector) and what ARIA widget we want to implement (which has standardized corresponding keyboard controls)
  • Highlight special areas that are not widgets, but where we want to implement additional keyboard controls regardless (e.g. jumping between search results)
• Implement shortcuts, including user settings to override them and events to track whether they are used
• Think about how to educate users of these shortcuts. It would probably be useful to have a similar visual for the different areas as the one from the above step that we can include in the app/docs for the user for education.
  • Keyboard shortcut quick-help
  • Docs page

[github-actions]

Heads up @AlicjaSuska @felixfbecker @umpox @valerybugakov @5h1rU @pdubroy - the "team/frontend-platform" label was applied to this issue.

[pdubroy]

Based on https://docs.google.com/document/d/1_r8aikiE-zwn0ZkWmOilynNVA3HfmF9Mglgg6ZEkkls/edit?disco=AAAAH93ixxE I don't know if we have everything we need to write this RFC yet.

[umpox]

Just for further context:

We've prioritised accessibility a lot lately, and I think it would be wise to re-review this RFC once we have finished our efforts in https://github.com/sourcegraph/sourcegraph/issues/31476.

Reasoning: We've made our application accessible with basic, built-in, keyboard shortcuts. This RFC focuses more on "power users". That is good, but there is also a lot of additional nuance that we need to account for the ensure these shortcuts are still accessible.

Some aspects, like changing how tab or arrow keys behave, might not be complaint with our accessibility standards

[felixfbecker]

@quinnkeast Here's what I think are the next steps:

1. Resolve open comments in the RFC, in particular:
   • Alignment with established accessibility concepts (landmark areas and widgets, vs "navigation areas" and "application areas")
2. Audit the main screens of the app (blob view, search results). I suggest creating a Figma for this with screenshots we can overlay with rectangles and annotations.
   • Highlight the landmark areas and which keyboard shortcuts we want to use for jumping to them.
   • Highlight widgets that currently do not have standard keyboard controls (e.g. file tree, revision selector) and what ARIA widget we want to implement (which has standardized corresponding keyboard controls)
   • Highlight special areas that are not widgets, but where we want to implement additional keyboard controls regardless (e.g. jumping between search results)
3. Implement shortcuts, including user settings to override them and events to track whether they are used
4. Think about how to educate users of these shortcuts. It would probably be useful to have a similar visual for the different areas as the one from the above step that we can include in the app/docs for the user for education.
   • Keyboard shortcut quick-help
   • Docs page

[quinnkeast]

I agree with all of these steps. I'll self-assign this issue and review #1 on your list, then follow up on #2 soon.

[quinnkeast]

Updates:

• I've revised the RFC based on comments and further thinking.
• I'm going to use this Figma file to audit the main screens of the app based on the latest revision of the proposal.