GitLab keyboard shortcuts: single-key bindings vary by page and can't be customized

Documented behavior

GitLab's web UI documents a fixed keyboard shortcut set: "?" opens the shortcuts overlay, "g" followed by a letter jumps between top-level areas, and "t" opens the file finder on project pages. Shortcuts are suppressed while focus sits in text inputs or textareas so typing never triggers navigation. These bindings match the documentation as of the 17.x-era docs; exact lists can shift between releases.

Constraints and open points

Two properties complicate keyboard-only use. Single-key shortcuts are context-dependent — active on some pages, absent on others — so muscle memory is unreliable, and the suppression boundary around focus changes and rich text editors is easy to misread when navigating by keyboard alone. The shortcut set is also fixed: configurable-binding requests remain open feature requests, so customization is a product decision, not a documented capability. Both points fall under WCAG 2.1 success criterion 2.1.1 (Keyboard), inside GitLab's stated WCAG 2.1 Level AA conformance goal.

The unresolved decision is whether activation should follow one uniform, documented rule — and whether customization should exist at all.

1. Should single-key shortcuts be active uniformly outside editable fields, or is page-scoped availability intentional and worth documenting as such?
2. If customizable bindings were introduced, should they override defaults per binding, and how would they interact with input suppression?