probeo

How to fix duplicate accesskey values?

accesskeys page

The issue

A keyboard shortcut that two elements share doesn’t reliably do anything. Depending on the browser, the key moves focus to the first element, cycles between them, or activates one without saying which. People who use shortcuts to move around a page can’t predict where they will land.

The cause is usually a repeated component or template: a header and a footer both define accesskey="s" for search, or a list renders the same key on every item. Access keys also share the keyboard with the browser’s and the screen reader’s own shortcuts, which is why many sites don’t use them at all.

Scope

Every visible element with an accesskey is checked against every other. Values are compared without regard to case, so S and s are the same key. Every element that shares a value is reported, not just the second one.

How to check you have it

  • In probeo: the page reports accesskeys, “accesskey attribute value should be unique”, as serious. It is a best practice rule rather than a WCAG criterion. The detail names the repeated key.
  • By hand: search the page source for accesskey= and compare the values.
  • With a tool: axe DevTools has a rule with the same name.

The fix

Give each element its own accesskey, or remove the attribute.

If the shortcuts are used, keep one per destination and document them on the page, since nothing in the browser lists them. If nobody relies on them, removing them is the simpler fix and avoids clashes with assistive technology.

Done when: no two visible elements share an accesskey, and the check above comes back clean.

Do not

  • Do not render the same accesskey inside a repeated component.
  • Do not assume S and s are different keys.
  • Do not add access keys without telling users what they are.

FAQ

Should a site use accesskey at all?

It can, for a small set of documented shortcuts. The keys also need a modifier that varies by browser and operating system, which makes them hard to discover, so many sites leave them out.

Does an accesskey on a hidden element count?

No. Hidden elements are skipped. A key that is unique only because its duplicate is hidden will clash once that element is shown.

What is the difference between this and a WCAG failure?

This rule is a best practice. A clash makes shortcuts unreliable, but WCAG doesn’t require access keys or set rules for their values.

Which product detects this

Probeo checks this on every page of your site as part of Site Clarity. This page explains one instance; the product tells you every page that has it.