Navigating Moodle by keyboard is essentially non existent compared to lots of modern web apps. This is different from basic keyboard accessibility this is about adding rich keyboard navigation across the whole site in a holistic way. It would be very useful for both power users and for accessibility.
What I'm proposing is that there is both a js api and a pure markup api where any UI component can declare a keyboard shortcut and moodle core does the heavy lifting of not only wiring up the events but also grouping and automatically building inline keyboard help based on the declarations.
So there could be markup something like the links in the top level nav: (html simplified for clarity)
<a mdl-shortcut="g h" href="https://moodle.edu/">Home</a>
<a mdl-shortcut="g d" href="https://moodle.edu/my/">Dashboard</a>
<a mdl-shortcut="g c" href="https://moodle.edu/my/courses.php">My courses</a>
<a mdl-shortcut="g a" href="https://moodle.edu/search.php">Site administration</a>
Note the custom mdl-shortcut="g h" attributes. All of the various shortcuts on the page would get bundled together and shown in a help dialog when ? is pressed which has become the de facto keyboard shortcut for keyboard shorts help.
In the help, related sets of shortcuts could be optionally ordered and grouped with additional attributes mdl-shortcut-order and mdl-shortcut-component. The component can be declared at any level and any shortcuts inside it would inherit that group unless overridden further down, so for instance core could automatically add a shortcut group around the main div when rendering a course activity and then another one deeper at the activity level so any UI added gets a pretty good default.
In most cases the shortcut is simply equivalent to navigating to an existing link or button, but there would be a js api for when you need more bespoke behavior.
A proposed starting set of keyboard shortcuts, mostly based of the de facto standards from many apps that do this (eg github, jira, trello, google docs, slack, gmail)
|?||none (site)||Shows keyboard help|
|/||none (site)||Focuses on search, ie global search on most pages
or report builder search / admin search
|g d||none (site)||Go to dashboard|
|g h||none (site)||Go to homepage|
|g m||none (site)||Go to my courses|
|g a||none (site)||Go to Site administration|
|g c||none (site)||Go to my calendar|
|g i||none (site)||Go to my notifications inbox|
|g n||course||Go the next page, ie next activity,
next book page, next section
|e m||course||Toggle edit mode|
|left arrow||database||Previous entry|
|right arrow||database||Next entry|
|n or j||calendar||Next period|
|p or k||calendar||Previous period|
|t||calendar||Go to Today|
Avoiding clashes with OS and browser shortcuts
The api should have a basic understanding of common OS and browser shortcuts and throw an error if a plugin tried to register them, eg alt+tab or control+n. Most of the shortcuts should be a short sequence of chars which is extremely unlikely to be already in use.
Contextual and Disabled shortcuts
Because each page declares its own shortcuts sets of keys will come and go as you navigate around. There might be shortcuts which should be considered global but which don't make sense on a particular page, but they can still be declared on a link or button which is disabled, or some other specific way of marking it as disabled. Then it would still appear in the help modal in its same position but marked as disabled.
Help string for each shortcut
In general most of the help text shown in the modal can be determined automatically by core without extra input. ie if the shortcut starts with 'g' then it is a 'Go to %' shortcut and % can be the title of the link or button, and then fall back if no title to it's label. There would be an optional override for when more precise help text is needed, such as shortcut-title="Do something complex".
There are several very powerful but lightweight libraries that Moodle core would internally use like hotkeys:
In most cases I think the shortcuts would remain the same across languages but this could easily be at the discretion of the plugin declaring the shortcuts. ie a plugin could put the shortcut itself into a language string and allow it to be overridden in the same way as a date and time format string.
Examples in the wild