accesskey attribute value should be unique

The accesskey attribute provides a keyboard shortcut that lets users quickly activate or move focus to a specific element, typically by pressing the designated key in combination with a modifier key (such as Alt on Windows or Control + Option on macOS). When multiple elements share the same accesskey value, browsers handle the conflict inconsistently — some will focus the first matching element, others will cycle through matches, and some may ignore the duplicates entirely. This unpredictability undermines the purpose of access keys and creates a confusing experience.

This issue primarily affects users who rely on the keyboard to navigate, including people who are blind and use screen readers, users with low vision who cannot easily track a mouse pointer, and users with motor disabilities who depend on keyboards or keyboard-emulating input devices. For these users, a duplicated access key can mean they can never reach the intended element, or they reach the wrong one without realizing it.

This rule is classified as a Deque Best Practice. While it doesn’t map directly to a specific WCAG success criterion, it supports the broader principles behind WCAG 2.1.1 Keyboard (all functionality must be operable via keyboard) and WCAG 4.1.2 Name, Role, Value (user interface components must behave predictably). Duplicate access keys undermine keyboard operability by introducing unreliable shortcuts.

How to fix it

1. Find all elements on the page that use the accesskey attribute.
2. Identify duplicates — any accesskey value that appears on more than one element.
3. Assign a unique value to each element so no two share the same key.
4. Avoid conflicts with default browser and screen reader shortcuts. For example, many browsers reserve Alt + D for the address bar and Alt + F for the File menu.

A note of caution about accesskey

While fixing duplicates is important, be aware that the accesskey attribute has significant limitations in practice:

• Inconsistent browser support: Not all browsers implement access keys the same way, and modifier key combinations vary across operating systems.
• Conflict risk: Developer-defined access keys can override default browser or assistive technology shortcuts, potentially breaking expected functionality.
• Discoverability: Access keys are invisible to most users unless explicitly documented on the page.
• Localization issues: A key that makes sense as a mnemonic in one language (e.g., s for “Search”) may not work in another.

For these reasons, many accessibility experts recommend avoiding accesskey altogether and instead relying on well-structured headings, landmarks, and skip links for efficient keyboard navigation.

Examples

Incorrect: duplicate accesskey values

Both links use accesskey="g", so the browser cannot determine which element to activate.

<a href="https://google.com" accesskey="g">Link to Google</a>
<a href="https://github.com" accesskey="g">Link to GitHub</a>

Correct: unique accesskey values

Each link has a distinct accesskey value, so keyboard shortcuts work as expected.

<a href="https://google.com" accesskey="g">Link to Google</a>
<a href="https://github.com" accesskey="h">Link to GitHub</a>

Correct: removing accesskey in favor of better patterns

If access keys aren’t essential, consider removing them and providing clear navigation structure instead.

<nav aria-label="Main navigation">
  <a href="https://google.com">Link to Google</a>
  <a href="https://github.com">Link to GitHub</a>
</nav>

Learn more:

Deque Reference

Deque University - How To Fix

→