Unique accesskey values on every page

Accesskey values must not repeat within a page

Every accesskey attribute on a page must have a unique value.

This issue appears on links, buttons, and form controls that declare accesskey.

Duplicate values create unpredictable behavior for keyboard-only users, including people with low vision or mobility impairments.

Why It Matters

When two or more elements share the same accesskey, the browser may activate the first match or behave inconsistently. Users cannot predict which control will be triggered.

People who rely on the keyboard for speed or motor reasons lose a reliable shortcut. Low-vision users who navigate by keyboard may also miss their intended target and waste time recovering focus.

Conflicts can also interfere with assistive technology and built-in browser shortcuts, compounding confusion.

Common Causes

• Copy-pasting components that reuse the same accesskey value.
• Assigning the same mnemonic letter to multiple controls (e.g., multiple "s" shortcuts for different sections).
• Dynamic widgets injecting elements with accesskeys without a uniqueness check.
• Localized pages reusing letters that conflict in other languages.
• Lack of documentation or inventory of shortcuts across a page or template.
• Choosing keys that also collide with browser or OS shortcut conventions.

How to Fix

1. Decide whether accesskeys are necessary. Recommendation: avoid accesskeys unless you have a clear, documented use case, because support and discoverability vary by browser and OS.
2. If you keep accesskeys:
   • Inventory all elements with an accesskey on the page (including templates and injected content).
   • Assign a unique, single-character value to each accesskey per page.
   • Avoid letters commonly used by browsers/OS (example: conflicts with typical navigation and tab/window commands). Test on your supported browsers/OS.
   • Provide a visible help section listing available shortcuts and their targets.
   • Ensure the shortcut moves focus to the control (or activates it) and that focus is visibly indicated.
   • For localized content, choose appropriate characters per language and re-verify uniqueness after translation.
   • Add a linter or test that fails the build if duplicate accesskeys are found.
3. Always provide non-shortcut alternatives (clear navigation, skip links, landmarks, and logical tab order) so users who can’t or don’t use accesskeys aren’t blocked.

How to Test

Keyboard check:

• Find all elements with accesskey using DevTools (search for [accesskey]).
• Use the browser’s accesskey modifier + key (varies by browser/OS) for each value.
• Confirm exactly one element responds, the intended target is activated or focused, and visible focus is present.

Screen reader check:

• With a screen reader running (e.g., NVDA, JAWS, VoiceOver), try the accesskey modifier + key.
• Confirm the shortcut still triggers the correct element and does not conflict with common screen reader commands.

Mobile/touch check:

• Accesskeys are largely unsupported on mobile. Verify that equivalent functionality is available via standard controls and headings/landmarks. Ensure all actions are reachable by touch and by sequential keyboard focus.

Checklist:

• No duplicate accesskey values on the same page.
• Shortcuts are documented and discoverable.
• Visible focus appears when focus moves via a shortcut.
• All actions are reachable without accesskeys.
• Localized pages maintain uniqueness after translation.

Good Example

<nav aria-label="Shortcuts">
  <p>Keyboard shortcuts:</p>
  <ul>
    <li>h = Go to Home</li>
    <li>k = Open Help</li>
    <li>n = Jump to News</li>
  </ul>
</nav>

<a href="#home" accesskey="h" id="home-link">Home</a>
<a href="#help" accesskey="k" id="help-link">Help</a>
<a href="#news" accesskey="n" id="news-link">News</a>

Bad Example

<!-- Duplicate accesskey "s" used twice -->
<button accesskey="s" id="save-btn">Save</button>
<a href="#search" accesskey="s" id="search-link">Search</a>

Quick Checklist

• Each accesskey value is unique per page.
• Shortcuts are optional; core tasks work without them.
• Avoid keys that likely conflict with browser/OS shortcuts.
• Show a visible list of available shortcuts.
• Focus lands on the intended element and is visible.
• Recheck uniqueness after content changes or localization.
• Automate detection of duplicate accesskeys in CI.