# `react-doctor/no-access-key`

Don't use `accessKey` — it conflicts with assistive-technology shortcuts.

- **Category:** Accessibility
- **Severity:** warn
- **Source:** oxlint-plugin-react-doctor
- **Framework:** global
- **Enabled when:** always
- **Documentation:** <https://oxc.rs/docs/guide/usage/linter/rules/jsx_a11y/no-access-key>

## Validation prompt

Use this to decide whether a fired diagnostic is real or a false positive.

Fires on any JSX element carrying an `accessKey` attribute (matched case-insensitively, so `accesskey` and `acCesSKeY` count) whose value is a string literal (`accessKey="h"`), a non-empty expression container (`accessKey={accessKey}`, `accessKey={"y"}`), or any template literal — even one that only interpolates `undefined` like `` accessKey={`${undefined}`} ``. The only carve-outs are the bare `undefined` identifier (`accessKey={undefined}`), an empty expression container `{}`, and a value-less attribute. False positive: there is essentially none — every value-bearing `accessKey` genuinely creates the conflict, so confirm unless the value provably resolves to `undefined` at runtime, which the static check can't see through a variable.

## Fix prompt

Use this once validation confirms the diagnostic is real.

Remove the `accessKey` attribute entirely — `<button accessKey="s">Save</button>` becomes `<button>Save</button>`. Author-assigned access keys collide with screen-reader and OS-level keyboard shortcuts, so there is no safe value to keep; if a keyboard shortcut is genuinely required, implement it with a documented, user-discoverable handler instead of `accessKey`. See https://oxc.rs/docs/guide/usage/linter/rules/jsx_a11y/no-access-key