Powered by
Keyboard & focus
Two or More Elements Share the Same Keyboard Shortcut
When two elements use the same `accesskey` shortcut, pressing it may reach the wrong one, or only ever the first, so people can't rely on it.
accesskeysBest practiceBest practice — not a WCAG requirement, but it helps people all the same.
- Status
- ModerateModerate — An annoyance, with a workaround.CurrentScanners run this rule today.
- Owner
- DesignDevTest
- Audit
- AutomatedA scanner finds it, and a clean scan means it's fixed.
Why it matters
The accesskey attribute gives an element a keyboard shortcut. Some people use shortcuts to avoid many key presses or mouse moves.
If two elements share a shortcut, browsers handle it differently. Some jump to the first one only, some cycle between them, and some do nothing useful. The shortcut stops being a shortcut.
Who it affects
| Who | What they experience | Impact |
|---|---|---|
| Keyboard-only users | They press the shortcut and land on the wrong link or button, or nothing obvious happens. | High impact |
| Screen reader users | They may hear the same shortcut announced on two elements, then reach only one of them. | Partial impact |
| Cognitive and neurodivergent users | A shortcut that does different things at different times is confusing and hard to trust. | Partial impact |
| Motor and dexterity | Shortcuts save them effort, and a broken one means extra key presses or mouse moves. | Partial impact |
Business & product impact
| Area | Why | Impact |
|---|---|---|
| Legal | This is a best practice, not a WCAG 2.2 Level AA requirement on its own. Broken shortcuts still add to a poor keyboard experience in a complaint under Australia's Disability Discrimination Act. | Low impact |
| Conversion | Few people use `accesskey`, so the sales impact is usually small. | Low impact |
| SEO | No search benefit at all. | Low impact |
| Brand trust | Shortcuts that misfire make a site feel careless to power users. | Low impact |
| Cost to fix | A quick change to one attribute. Often the cheapest fix is to remove `accesskey` entirely. | High impact |
Fixing it in code
Give each shortcut its own key
Don't
<a href="/search" accesskey="s">Search</a>
<a href="/shop" accesskey="s">Shop</a>A screen reader says: “Search, link, Alt S … Shop, link, Alt S”
Do
<a href="/search" accesskey="s">Search</a>
<a href="/shop" accesskey="p">Shop</a>A screen reader says: “Search, link, Alt S … Shop, link, Alt P”
Each key now leads to exactly one place.
Or remove shortcuts you don't need
Don't
<button accesskey="m">Menu</button>
<button accesskey="m">More</button>A screen reader says: “Menu, button, Alt M … More, button, Alt M”
Do
<button>Menu</button>
<button>More</button>A screen reader says: “Menu, button … More, button”
No shortcut is better than one that clashes with another, or with the browser or screen reader.
Designer's handoff note
If the product needs shortcuts, keep one list of every key and what it does.
Tell people the shortcuts exist, for example on a help page. Hidden shortcuts help almost no one.
Quick test
Tool
Browser developer tools (opens in a new tab) and the keyboard
Checklist
- Pass
- Every key is used once and takes you to the right element.
- Fail
- A key appears twice, or the shortcut goes to the wrong place.
What a green scan still misses
A scanner finds repeated keys. It can't tell if a unique key clashes with a browser or screen reader shortcut, or whether anyone can find out the shortcuts exist.
Reference
- Rule ID
accesskeys- Raised by
- axe-core: “accesskey attribute value should be unique”
- WCAG
- Best practice — not a WCAG requirement
- Last reviewed
- 14 October 2026