What causes "No access key attribute allowed." in oxc-project/oxc?

Remove the `accessKey` attribute entirely.

No access key attribute allowed.

Error message

No access key attribute allowed.

What it means

This is the `jsx_a11y/no-access-key` rule in oxlint. It fires when any JSX element carries an `accessKey` prop (matched case-insensitively via `has_jsx_prop_ignore_case`). Browser access-key shortcuts frequently collide with shortcuts used by screen readers and keyboard-only users, so jsx-a11y bans the attribute entirely.

Source

Thrown at crates/oxc_linter/src/rules/jsx_a11y/no_access_key.rs:12

use oxc_ast::{
    AstKind,
    ast::{JSXAttributeItem, JSXAttributeValue},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;

use crate::{AstNode, context::LintContext, rule::Rule, utils::has_jsx_prop_ignore_case};

fn no_access_key_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("No access key attribute allowed.")
        .with_help("Remove the `accessKey` attribute. Inconsistencies between keyboard shortcuts and keyboard commands used by screen readers and keyboard-only users create accessibility complications.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoAccessKey;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Enforces that the `accessKey` prop is not used on any element to avoid complications with keyboard commands used by a screen reader.
    ///
    /// ### Why is this bad?
    ///
    /// Access keys are HTML attributes that allow web developers to assign keyboard shortcuts to elements.
    /// Inconsistencies between keyboard shortcuts and keyboard commands used by screen readers and keyboard-only users create accessibility complications so to avoid complications, access keys should not be used.
    ///
    /// ### Examples

View on GitHub (pinned to e1e7af627c)

Solutions

Remove the `accessKey` attribute entirely.
If a keyboard shortcut is genuinely needed, implement it with a `keydown` listener on a focused container or a well-tested library, avoiding single alt+letter combos.
Disable the rule inline only if the shortcut has been verified against screen-reader shortcuts.

Example fix

// before
<button accessKey="s" onClick={save}>Save</button>

// after
<button onClick={save}>Save</button>

Defensive patterns

Strategy: validation

Validate before calling

npx oxlint --jsx-a11y/no-access-key src/ # or: rg -n 'accessKey' --iglob '*.{tsx,jsx}' src/

Prevention

Never add accessKey attributes; treat the attribute as banned by convention.
Implement shortcuts via a global keydown handler with documented, non-conflicting combos.
Code-review grep for 'accessKey' before merging feature branches.

When it happens

Trigger: Any JSX opening element with an `accessKey` / `accesskey` attribute, regardless of element type or value. The diagnostic is raised from the constructor at crates/oxc_linter/src/rules/jsx_a11y/no_access_key.rs:11 when the prop is found.

Common situations: Legacy enterprise apps that added keyboard shortcuts via `accessKey`; copy-pasted HTML converted to JSX; enabling the jsx-a11y strict preset on an older codebase; developers unaware that screen readers reserve alt+letter combinations.

Related errors

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/7a8b7ca871725fb1. Report an issue: GitHub.