Problem/Motivation
At the moment hotkeys are rarely used in the context of Drupal. There is currently no module in Drupal core that is providing any hotkeys. In the contrib space there are only three, the coffee, the tour, and the admin_toolbar module (see
https://www.drupal.org/docs/extending-drupal/contributed-modules/compari... →
- but maybe there are even more?). And Experience Builder is going to require a more extended set of hotkeys - the discussion is currently happening in
🌱
[META] Define strategy for keyboard shortcuts
Active
. In summary there is a set of problems that applies either partially or completely to all the aforementioned modules:
- For the three contrib modules it is easy to miss the availability of a hotkey in the docs and/or the projects detail page, nor is there any option in the settings to override and adjust those hotkeys to your own liking.
- It is neither possible to view a list of hotkeys available globally nor the ones in the context of the current page.
- It is challenging to memorize and recall those hotkeys - in particular for people with a small working memory.
- For module maintainers there is no consistent and easy way to add a new hotkey to their module.
- It is not guaranteed that all the modules are using the same modifier key(s).
- The more hotkeys are being added the more rises the odds of duplicates.
- There does not exist an UI component for overriding hotkeys or fields in general in the Drupal Design System - the three contrib modules don’t even have that option.
During the competitive gap analysis at the beginning of the accessibility track for Drupal CMS, we have compared
the accessibility tools and features the main CMSes have →
📌
Analyze alternatives solutions to Drupal to identify gaps
Active
. During that audit the group noticed a basic implementation in Joomla that could potentially solve the previously outlined set of problems for keyboard users in Drupal. On many pages within the admin UI Joomla provides instructions at the bottom how to access keyboard shortcuts:
That key combination opens a dialog modal containing a cheat sheet with all the available keyboard shortcuts for Joomla:
Problem is, those instructions are hard to discover for non-sighted users due to the lack of an associated heading and/or landmark, it is uncertain how well things perform with a regular key (j) instead of a modifier key, and the list of hotkeys is rather short, fixed, and static, there is no real flexibility with the option of modification by the user or a module/plugin.
Steps to reproduce
Proposed resolution
Based on the discussions with @batigolix, @katannshaw, @mherchel, @the_g_bomb, and myself, we would propose the creation of an API for registering, managing, and accessing hotkeys. An outline of the suggested set of features and requirements:
- Provide a simple way to set the desired hotkeys(s) in module code for triggering a specific function or button. Set if a hotkey could be triggered globally or solely in the scope of a specific page. Consider also how to handle the case of hotkeys that are set within upstream JavaScript libraries modules that provide an integration into Drupal (for example SkipTo).
- Use a modifier key as part of the hotkey to be in line with
WCAG2.2 SC2.1.4 →
. Decide on the modifier key that has the least number of assignments of keys across operating systems and also ensure that no hotkey set in Drupal is overriding any hotkey of the operating system.
- The API should aggregate all hotkeys defined in code across all the installed modules into a single list. It should intervene in case of conflict(s). If two modules have defined the same hotkey(s), then the person installing the module with the colliding hotkey(s) has to pick global overrides(s) for the site. If one of the modules that is containing the colliding hotkey is uninstalled and the remaining module is the one overridden, also ask the person uninstalling if it should changed back from the fallback to the initially set hotkey.
- Provide an interface component to override hotkeys as well as signage how to label overridden hotkeys.
- Add a button to every page for logged in users. Make sure the button is easily discoverable by a visually hidden heading and or landmark. The button should be trigger-able by click, key press when the button is in focus, or directly by hotkey. Also provide an option in the settings for that API to decide on the position of the button and if it is displayed or not - cuz as soon as a user knows about the existence of that hotkey, the button to the cheat sheet does not need to be shown anymore, it is still directly accessible via the hotkey.
- When the button was triggered, a dialog modal with the list of available hotkeys should be displayed. In the upper section the global hotkeys applicable for the entire site for triggering things like a Tour, or the Coffee module interface, and in the bottom section the list of hotkey available in the current context for example if you are on an Experience Builder page
- Add a local item to the user page. Have one or more secondary tabs, where the user is able to decide on for example the position and if the button is displayed or not, as well as the list of all the available hotkeys with the option to override each of them.