On each web page, can keyboard shortcuts that use only one key (lowercase or uppercase letter, punctuation, digit or symbol) be controlled by the user?
A NVDA user navigates with the H key to jump between headings, B for buttons, F for fields. If your site has defined these same letters as JavaScript shortcuts, it triggers your features instead of reading the page. The conflict is silent, unpredictable, sometimes blocking.
Criterion 12.10 targets single-key shortcuts implemented by the site: a letter, a number, a symbol, without a modifier key (Ctrl, Alt, Shift). YouTube with "k" for pause, Gmail with "c" to compose a message. These shortcuts do not come from the browser or system—they come from your JavaScript.
To validate the criterion, at least one of these three conditions must be met for each shortcut: the user can disable it, the user can remap it with a modifier key ("k" becomes "Ctrl+k"), or the shortcut is only active when keyboard focus is positioned on the affected component.
The third option is often the fastest to implement. Listen to the keydown event on the component itself rather than on document. No configuration interface to build, no preference to store in a database.
Un test to verify that single-character keyboard shortcuts are deactivatable
Disabling or limited scope of single key shortcuts
- Identify all single-key shortcuts in the document: letter (lowercase or uppercase), number, punctuation or symbol, without Ctrl, Alt or Shift.
- For each identified shortcut, verify that at least one of these three conditions is met: a. An accessible mechanism allows the user to disable the shortcut; b. An accessible mechanism allows the user to reconfigure it with a modifier key (Ctrl, Alt, Shift…); c. The shortcut is only active when keyboard focus is positioned on the component to which it is linked.
- If no condition is met for at least one shortcut, the test fails.
Examples
❌ Non-compliant : Global shortcut captured on document — non-compliant
<video id="player" src="conference.mp4" controls></video>
<script>
document.addEventListener("keydown", function(event) {
if (event.key === "k") {
const video = document.getElementById("player");
video.paused ? video.play() : video.pause();
}
});
</script>The "k" shortcut is active everywhere on the page, regardless of focus position. A JAWS user who presses K to navigate to a link triggers the video pause instead. The conflict is invisible in the interface and can completely disorient the user.
✅ Compliant : Shortcut limited to component focus — compliant
<video id="player" src="conference.mp4" controls
tabindex="0"
aria-label="Digital accessibility conference 2025"></video>
<script>
const player = document.getElementById("player");
player.addEventListener("keydown", function(event) {
if (event.key === "k") {
player.paused ? player.play() : player.pause();
}
});
</script>The "k" shortcut only triggers if keyboard focus is on the video element. When the user navigates elsewhere on the page, the k key does not interfere with their screen reader. No configuration interface is needed: it's the least expensive solution to implement.
Tips and pitfalls
⚠️ Shift+Letter remains a single-key shortcut
A shortcut triggered by uppercase "K" (Shift+K) is still within the scope of criterion 12.10. Shift alone is not a sufficient modifier key. To be compliant, the shortcut must include Ctrl, Alt or an equivalent combination. Check event.ctrlKey or event.altKey in your handler before concluding compliance.
⚠️ Third-party library shortcuts commit you as well
A video player or interactive map embedded via a JavaScript library can introduce single-key shortcuts without you explicitly coding them. You remain responsible for the entire page. Check if the library offers a disable option (keyboard: false, shortcuts: false). If not possible, document the gap in your accessibility statement.
💡 The focus-only solution requires no user interface
Constraining a shortcut to focus on a component (addEventListener on the element rather than on document or window) is the only one of the three compliant options that does not require building a configuration panel. It is the recommendation to remember for media players, keyboard-active carousels, and complex ARIA widgets.
⚠️ Shortcuts in ARIA widgets (grids, combobox, sliders)
A data grid or combobox can legitimately use arrow keys or letters for internal navigation. These shortcuts are compliant if they only work when focus is inside the widget. The WAI-ARIA Authoring Practices Guide (APG) patterns document the expected keyboard behaviors for each component type.
⚠️ Browser and system shortcuts: out of scope
Ctrl+T, Ctrl+L, F5, NVDA or JAWS shortcuts: criterion 12.10 does not address them. It only targets what your JavaScript implements via addEventListener. If the triggered key comes from a code-side handler, it is in scope. If it comes from the browser or screen reader, it is not.
Frequently asked questions
How do you identify single-key shortcuts on a page during an audit?
Look in the JavaScript for all addEventListener('keydown', ...) or addEventListener('keypress', ...) attached to document or window. Then examine the conditions: if the handler triggers on event.key === 'k' without checking event.ctrlKey, event.altKey or event.metaKey, you have a single-key shortcut within scope. In manual testing: navigate with NVDA enabled and press H, K, J, M, B, 1 through 6—any unexpected trigger is a warning signal.
Why are NVDA or JAWS shortcuts outside the scope of RGAA criterion 12.10?
No. Assistive technologies manage their own shortcuts independently of your code. The criterion only targets what your JavaScript implements. However, your shortcuts can conflict with those of the screen reader: this is precisely the problem that 12.10 seeks to prevent.
How do you document the keyboard shortcuts present on a page for RGAA criterion 12.10?
RGAA 12.10 does not require explicit documentation of shortcuts. However, if you choose the disable or reconfiguration solution, the mechanism must be accessible to the user, which implies that they know these shortcuts exist. A mention in the help or in an accessibility panel is a good practice, but not a requirement of the criterion.
How is the accesskey attribute on links handled by RGAA criterion 12.10?
Yes. The accesskey attribute defines single-key shortcuts and falls within the scope of criterion 12.10. Its behavior varies greatly depending on browsers and screen readers, and it frequently causes conflicts. Most accessibility experts advise against its use. If you use it, verify that one of the three compliance conditions is met.
How do you verify compliance with RGAA criterion 12.10 without access to source code?
Open the developer tools (Sources or Debugger tab), then add a global event listener via the console: document.addEventListener('keydown', e => console.log(e.key, e.target)). Navigate the page and press different keys. If functions are triggered when focus is not on a video or interactive component, the criterion is potentially failing.