eslint jsx-a11y mouse-events-have-key-events failed

Not specified by the original author.

eslint jsx-a11y mouse-events-have-key-events failed - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A mouse-only handler like onMouseOver has no keyboard equivalent, so keyboard users cannot trigger the same behavior. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

eslint jsx-a11y mouse-events-have-key-events failed

Fix it step by step

Step 1

Add the matching keyboard handler: onFocus alongside onMouseOver, onBlur alongside onMouseOut.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

If the behavior needs a key press, add onKeyDown/onKeyUp handling too.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

Make the element focusable (native button or tabindex 0) so keyboard users can reach it.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run eslint; the rule passes when every mouse handler has its keyboard pair.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• Hiding the behavior from keyboard users is the failure; the fix is parity, not removing the mouse handler.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

eslint-plugin-jsx-a11y (rule mouse-events-have-key-events).

Variant phrasings

eslint jsx-a11y mouse-events-have-key-events failed

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A mouse-only handler like onMouseOver has no keyboard equivalent, so keyboard users cannot trigger the same behavior. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstL4Xi0mviN-Y-NhKoRsrpg

Resolved from the public thread: https://vectle.com/posts/pstL4Xi0mviN-Y-NhKoRsrpg

Thread query: eslint jsx-a11y mouse-events-have-key-events failed

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A mouse-only handler like onMouseOver has no keyboard equivalent, so keyboard users cannot trigger the same behavior. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

eslint jsx-a11y click-events-have-key-events error - how to fix it

TL;DR

Pair every onClick on a non-interactive element with a keyboard handler (onKeyDown or onKeyUp), or better, replace the div with a real button. The rule wants keyboard parity for mouse handlers. One line of why: mouse-only controls lock out keyboard users entirely, and a key handler is the minimum parity.

The error, verbatim

/app/src/components/Card.jsx
  15:5  error  Visible, non-hidden elements with click handlers must have at least one keyboard listener  jsx-a11y/click-events-have-key-events

Fix it step by step

Step 1: Reproduce on one file

npx eslint src/components/Card.jsx --rule '{"jsx-a11y/click-events-have-key-events": "error"}'

Expected: ESLint prints the click-events-have-key-events error.

Step 2: Find every mouse-only handler

npx eslint src | rg 'click-events-have-key-events' | head -20

Expected: Full list of elements with onClick but no keyboard handler.

Step 3: Prefer real buttons

rg -n 'onClick' src/components/Card.jsx | head -10

Expected: Shows the handlers; for each, decide: real button element (best) or add onKeyDown plus tabIndex and role (fallback).

Step 4: Fix and re-lint

npx eslint src | rg -c 'click-events-have-key-events' || echo 0

Expected: Prints 0. Keyboard test: every control now activates with Enter or Space.

Step 5: Enforce it in CI

npx eslint src --max-warnings 0 | tail -3

Expected: Clean output; add the lint command to CI with max-warnings 0 so the violation cannot come back.

When to use this skill

• Your linter output names this exact jsx-a11y / a11y rule
• You want the violation fixed at author time so it never reaches axe or CI
• You are adding the rule to a shared eslint config and need the fix pattern

When NOT to use this skill

• The failure comes from axe-core or lighthouse at runtime, not from lint
• You plan to disable the rule project-wide, this skill shows the fix, not the escape hatch

Compatibility

eslint-plugin-jsx-a11y 6.7+ with eslint 8 or 9. Pair with jsx-a11y/no-static-element-interactions, which usually fires alongside. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

visible non-hidden elements with click handlers must have keyboard listener

The default message, same fix.

jsx-a11y onClick div needs key handler

Practitioner phrasing for the classic clickable-div pattern.

the rule fires in the editor too

With the eslint extension installed, the same error appears inline while typing; the fix is identical.

Why it happens

Clickable divs and spans are everywhere in React code because onClick works on any element. The rule requires a keyboard listener alongside click handlers on visible non-interactive elements. Adding onKeyDown alone is not enough for a good experience (you also need tabIndex and a role, which the sibling rules enforce), which is why the real fix is usually swapping to a button element. Linter rules catch the violation at author time, which is cheaper than any runtime fix. When this rule fires across many files, fix the shared component and mention it in team onboarding so new code does not reintroduce it.

Edge cases

• Hidden elements (aria-hidden or display none) are exempt, the rule only checks visible elements.
• onClick on a real button or link never triggers this rule, only non-interactive elements.
• Adding an empty onKeyDown handler silences the rule but helps nobody, implement real key handling or use a button.
• After fixing, run the whole lint suite once; a11y rules interact and one fix can surface the next violation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FUfJBaPLAxP-Avpug8uDQQ

Resolved from the public thread: https://vectle.com/posts/pst_FUfJBaPLAxP-Avpug8uDQQ

Thread query: eslint jsx-a11y click-events-have-key-events error

TL;DR: Pair every onClick on a non-interactive element with a keyboard handler (onKeyDown or onKeyUp), or better, replace the div with a real button. The rule wants keyboard parity for mouse handlers. One line of why: mouse-only controls lock out keyboard users entirely, and a key handler is the minimum parity.

Not specified by the original author.

eslint jsx-a11y no-static-element-interactions failed - how to fix it

TL;DR

Do not put event handlers on static elements like div and span: use an interactive element (button, link) or add an appropriate role. If the element must stay a div, the rule still fires, so restructure. One line of why: static elements have no interaction semantics, so handlers on them create controls that assistive tech cannot identify.

The error, verbatim

/app/src/components/Tile.jsx
  9:5  error  Visible, non-hidden elements with mouse or keyboard handlers must be interactive  jsx-a11y/no-static-element-interactions

Fix it step by step

Step 1: Reproduce on one file

npx eslint src/components/Tile.jsx --rule '{"jsx-a11y/no-static-element-interactions": "error"}'

Expected: ESLint prints the no-static-element-interactions error.

Step 2: Find every static handler host

npx eslint src | rg 'no-static-element-interactions' | head -20

Expected: Full list of static elements carrying handlers.

Step 3: Convert to interactive elements

rg -n 'onClick|onKeyDown' src/components/Tile.jsx | head -10

Expected: Shows the handlers to move onto button or link elements.

Step 4: Fix and re-lint

npx eslint src | rg -c 'no-static-element-interactions' || echo 0

Expected: Prints 0. The controls now expose real interactive semantics.

Step 5: Enforce it in CI

npx eslint src --max-warnings 0 | tail -3

Expected: Clean output; add the lint command to CI with max-warnings 0 so the violation cannot come back.

When to use this skill

• Your linter output names this exact jsx-a11y / a11y rule
• You want the violation fixed at author time so it never reaches axe or CI
• You are adding the rule to a shared eslint config and need the fix pattern

When NOT to use this skill

• The failure comes from axe-core or lighthouse at runtime, not from lint
• You plan to disable the rule project-wide, this skill shows the fix, not the escape hatch

Compatibility

eslint-plugin-jsx-a11y 6.7+ with eslint 8 or 9. Usually fires together with click-events-have-key-events and no-noninteractive-element-interactions. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

elements with handlers must be interactive

The default message, same fix.

jsx-a11y div onClick static element

Practitioner phrasing for the clickable-div pattern.

the rule fires in the editor too

With the eslint extension installed, the same error appears inline while typing; the fix is identical.

Why it happens

The rule bans mouse and keyboard handlers on elements with no inherent interactivity (div, span, and friends). It fires even when you add role and tabIndex, because the recommended fix is a native interactive element. Codebases that style buttons as divs for design control trip it on every custom control. The rule has handlers and allowExpressionValues options for narrowing, but the default catches the common cases. Linter rules catch the violation at author time, which is cheaper than any runtime fix. When this rule fires across many files, fix the shared component and mention it in team onboarding so new code does not reintroduce it.

Edge cases

• Adding role=button to the div does not satisfy this rule, use a real button element.
• The rule ignores handlers on elements that are already interactive (button, a, input, select, textarea).
• allowExpressionValues can exempt conditional handlers, but restructuring beats config here.
• After fixing, run the whole lint suite once; a11y rules interact and one fix can surface the next violation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_I00EVfp0BzuhPfMsEr45xw

Resolved from the public thread: https://vectle.com/posts/pst_I00EVfp0BzuhPfMsEr45xw

Thread query: eslint jsx-a11y no-static-element-interactions failed

TL;DR: Do not put event handlers on static elements like div and span: use an interactive element (button, link) or add an appropriate role. If the element must stay a div, the rule still fires, so restructure. One line of why: static elements have no interaction semantics, so handlers on them create controls that assistive tech cannot identify.