A maintenance console has an old Save button with accesskey="s". Staff using one browser can activate it, while staff using another report that the same keys do something else. Before adding a page-wide keyboard listener, determine whether the application intends to keep a browser-assigned access key at all.
Identify what the markup actually promises
<button id="save-note" type="button" accesskey="s">
Save note
</button>
The attribute uses a printable character as the hint. It is not a shortcut-expression field: writing accesskey="Ctrl+S" does not define that combination. Keep the ordinary button reachable by Tab and usable by click or touch.
MDN lists different activation combinations by platform and browser. For example, its Windows entries distinguish Chrome's Alt+key from Firefox's Alt+Shift+key. Those examples explain an existing discrepancy; they are not a compatibility guarantee for every keyboard layout, assistive technology setup, or future browser version.
If your application already displays “Ctrl+S to save” beside this button, remove that claim unless a separate, tested shortcut implementation provides it. Changing the attribute's letter does not fix the unsupported modifier claim.
Display an assigned label only when the browser supplies one
accessKeyLabel can expose the browser-assigned combination. MDN marks the property as having limited availability, so code must handle an absent or empty value:
<p id="save-shortcut"></p>
const saveButton = document.getElementById('save-note');
const shortcut = document.getElementById('save-shortcut');
const assigned = saveButton.accessKeyLabel;
shortcut.textContent =
typeof assigned === 'string' && assigned
? `Browser access key: ${assigned}`
: 'Use the Save note button.';
The fallback deliberately does not present the bare s as a complete key combination. The attribute's character alone does not reveal the modifier keys. Keep this explanation visible; relying only on a hover tooltip makes discovery harder for keyboard and touch users. accessKeyLabel reference
Decide whether keeping the access key is worthwhile
For a public form used on many devices, removing the hint is often the appropriate choice:
saveButton.removeAttribute('accesskey');
shortcut.textContent = 'Use the Save note button.';
The button still works through its normal activation paths. The change removes an additional browser-assigned shortcut; it does not disable the action.
A controlled console may retain access keys after testing its actual supported environments. Document the chosen keys in its keyboard help and review translations and keyboard layouts. A letter that is easy to type on one layout may be inconvenient on another. Also consider what happens when focus is in a text field and when assistive technology is active.
The application keyboard shortcut guide covers JavaScript handlers for application-defined combinations. Use that route only when the application needs a defined command and can respect text-entry context and existing platform shortcuts. Adding a second mechanism to the same button can create duplicate or competing activation paths.
Verify the resulting action, not just the key event
Test the declared browser and operating-system combinations with the real console. Activate Save once and confirm that the intended note is saved once. Repeat while editing another field and with the accessibility tools the console supports. An observed key event alone does not prove the save handler completed or that no other command ran.
Finally, reach Save using Tab and activate it normally, then click it. The browser access key should remain an optional path. If it cannot coexist reliably with the supported environments, remove the attribute and keep the visible control and accurate help text.