How to Use Accesskeys Safely: Complete Guide (2026)

Why Accesskeys Are Almost Always a Problem

The accesskey idea was added to HTML 4 in 1999, before mainstream screen readers, before tabbed browsers, and before macOS used Cmd-based shortcuts. It hasn't aged well, and the conflicts it creates fall into five clear buckets.

• Browser conflicts. Every browser maps Alt+letter (Windows/Linux) and Ctrl+Option+letter (macOS Safari) differently. A page-defined accesskey="d" can either focus your widget or jump the user to the address bar — depending on which browser they happen to use.
• OS conflicts.System-level shortcuts (Cmd+S to save, Ctrl+W to close a tab, Cmd+Q to quit) win over page accesskeys on most platforms, so users either can't reach your shortcut or trigger something destructive trying.
• Assistive-technology conflicts. JAWS uses dozens of Alt+letter commands. NVDA uses Insert+letter. VoiceOver uses Ctrl+Option+letter. Page accesskeys overlap with all three keyspaces in unpredictable ways, and screen-reader users have no way to know which side will win on a given page.
• Locale and keyboard-layout conflicts. An accesskey="m"on a US keyboard sits where a comma sits on French AZERTY. Users on non-US layouts often can't physically reach the shortcut, or trigger it accidentally while typing.
• Discoverability problem.There is no standard browser UI that tells the user which accesskeys exist on a page. If you don't document them visibly, almost nobody finds them — and the ones who do are usually the ones triggering them by accident.

What the accesskeys Audit Catches

The automated accesskeys rule is intentionally narrow. It does not flag every accesskey use — it flags the cases where the markup is provably broken.

• Duplicate values. Two or more elements with the same accesskey on the same page. Only one wins, and which one is undefined across browsers.
• Multi-character values. accesskey="save" is invalid — only a single character is reliably supported by user agents.
• Empty values. accesskey="" declares a shortcut with no key, which serves no purpose and signals a templating bug.

The audit deliberately does not flag every potentially-conflicting letter, because there is no portable list of "safe" characters across browsers, OSes, and screen readers. That responsibility sits with you. The safe answer is almost always: don't use accesskey at all.

<!-- Bad: duplicate accesskey, plus collision with Cmd+S "Save" -->
<button accesskey="s">Search</button>
<button accesskey="s">Save draft</button>

<!-- Bad: multi-character value -->
<a href="/help" accesskey="help">Help</a>

<!-- Good: no accesskey. Use proper focus order + a skip link. -->
<a href="#main" class="skip-link">Skip to main content</a>

<!-- Good: a custom shortcut the user can disable -->
<script>
  // Only Ctrl+/ to focus search, with a user setting to opt out.
  const shortcutsEnabled = localStorage.getItem('shortcuts') !== 'off';
  document.addEventListener('keydown', (e) => {
    if (!shortcutsEnabled) return;
    if (e.ctrlKey && e.key === '/') {
      e.preventDefault();
      document.getElementById('search')?.focus();
    }
  });
</script>

How to Check Your Site for accesskey Issues

Most sites in 2026 have stray accesskeys left over from older templates or copy-pasted code. A quick audit pass surfaces them in seconds.

• Greadme deep scan — runs the full accessibility audit pass on a single page, surfaces every duplicate or invalid accesskey, and pairs each finding with an AI-generated fix or a one-click GitHub PR.
• Greadme crawler scan — checks every indexable page on the site so you catch accesskeys that only appear in one template (e.g. a legacy admin layout) without manually opening each route.
• Greadme AI visibility analyzer — confirms that the keyboard navigation issues an audit raises don't bleed into how AI search engines describe your interface.
• Chrome DevTools → Elements panel — search the DOM for accesskey= to spot every occurrence in the rendered HTML on a given page.
• Google Search Console → Page experience — usability regressions on key templates often correlate with stray accessibility attributes; cross-reference with your audit findings.
• Manual screen-reader pass — open the page in NVDA, JAWS, or VoiceOver and try each documented shortcut. If a shortcut steals focus from the screen reader, it's broken regardless of what the audit says.

7 Rules for Keyboard Shortcuts That Don't Hurt Users

Common accesskey Failures and How to Fix Them

accesskey vs Modern Keyboard Navigation Patterns

The right way to think about accesskeys in 2026 is to compare them with the patterns that have replaced them. In nearly every dimension, the alternatives win.

FAQ

Should I use the HTML accesskey attribute in 2026?

In almost every case, no. The conflicts with browser, OS, and assistive-technology shortcuts mean the attribute helps a small number of users while breaking a larger one. Use a skip link, ARIA landmarks, and (if your app needs power-user shortcuts) custom JavaScript bindings with a disable toggle.

What does the accesskeys audit actually fail on?

It fails on three concrete patterns: two elements sharing the same accesskey on a page, an accesskey value longer than one character, and an empty accesskey. It does not flag every potentially-conflicting letter, because there's no portable list of safe characters across the platform stack.

Which WCAG criteria relate to accesskeys?

Two are most relevant. SC 2.1.1 Keyboard (Level A) requires that everything be reachable from a keyboard, but accesskeys are not the way to do that — proper focus order is. SC 2.1.4 Character Key Shortcuts (Level A, added in WCAG 2.1) requires that single-character shortcuts be remappable, disable-able, or only active on focus — and the native accesskey attribute satisfies none of those.

Why do screen readers conflict with accesskeys?

Screen readers reserve large blocks of the keyboard for their own commands. JAWS uses dozens of Alt+letter commands, NVDA uses Insert+letter, and VoiceOver uses Ctrl+Option+letter. Web pages that bind accesskeys to those same key combinations either get overridden silently or break the screen-reader workflow.

Are there any safe letters to use as an accesskey?

There is no portable safe set. Letters most likely to collide include D, F, R, S, T, W, P, L, and H, but every browser, OS, and screen reader maintains its own list. If you keep one accesskey on a page (for a search box or skip link), pick a less-common character, document it in the visible UI, and accept that some users still won't be able to reach it.

Do AI search engines like ChatGPT and Perplexity care about accesskeys?

Indirectly. AI search systems most often surface pages that already rank well in traditional search, and accessibility issues — including auditor warnings — feed into the page-experience signals Google uses. A site littered with broken accesskey declarations also tends to have other accessibility issues that AI extractors stumble on, which reduces citation odds.

What's the right alternative for application-style keyboard shortcuts?

Bind shortcuts in JavaScript, expose them in a visible help dialog, allow the user to disable them entirely (or remap them), and where possible scope the listener to the focused component. This pattern satisfies WCAG 2.1.4 Character Key Shortcuts and avoids every layer of the accesskey conflict stack.