You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: exclude canvas, and audio/video without controls, from interactive tags
Tighten the interactive-element derivation to mirror jsx-a11y's layered
approach: aria-query's elementRoles (with attribute constraints) is the
primary signal, axobject-query is only a fallback for tags with no
interactive elementRoles entry.
Deviations for common real-world false positives:
- canvas is excluded from the AX fallback — its AXObject is widget-typed
but aria-query assigns it no inherent ARIA role, and authors
legitimately use role="img" / role="presentation" on it.
- audio / video are only treated as interactive when the controls
attribute is present, matching user-facing-widget reality.
Adds tests for: canvas with role=img/presentation/none (valid); audio
and video without controls + non-interactive role (valid); audio and
video with controls + role=presentation (invalid). Existing tr/td/th/
button/input/a[href] tests unchanged.
Copy file name to clipboardExpand all lines: docs/rules/template-no-interactive-element-to-noninteractive-role.md
+9-2Lines changed: 9 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,14 @@
4
4
5
5
Disallow native interactive elements from being assigned non-interactive ARIA roles.
6
6
7
-
Assigning a non-interactive role to a native interactive element (e.g. `<button role="heading">`) strips the element's built-in keyboard, focus, and activation semantics — leaving users with a broken widget. The [first rule of ARIA use](https://www.w3.org/TR/html-aria/#rule1) says don't use ARIA if native semantics already cover the job; this rule enforces the related corollary.
7
+
Assigning a non-interactive role to a native interactive element (e.g. `<button role="heading">`) strips the element's built-in keyboard, focus, and activation semantics — leaving users with a broken widget. The [first rule of ARIA use](https://www.w3.org/TR/using-aria/#rule1) says don't use ARIA if native semantics already cover the job; this rule enforces the related corollary.
8
+
9
+
The interactive-element set is derived in layers, mirroring [jsx-a11y's `isInteractiveElement`](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/src/util/isInteractiveElement.js): aria-query's `elementRoles` (with its attribute constraints, e.g. `<a href>`, `<input type="…">`, `<select multiple>`) is the primary signal; axobject-query's AX-tree mapping is consulted only as a fallback for tags that have no interactive `elementRoles` entry.
10
+
11
+
Two deviations for real-world false-positive patterns:
12
+
13
+
-`<canvas>` is **not** treated as inherently interactive. Its AXObject is widget-typed but aria-query assigns it no inherent role; authors legitimately set `role="img"` or `role="presentation"` on canvases.
14
+
-`<audio>` and `<video>` are only interactive when the `controls` attribute is present. Without it they render no user-operable UI (e.g. background / decorative media).
8
15
9
16
## Examples
10
17
@@ -32,5 +39,5 @@ This rule **allows** the following:
32
39
## References
33
40
34
41
-[WAI-ARIA 1.2 — Role taxonomy](https://www.w3.org/TR/wai-aria-1.2/#roles_categorization)
35
-
-[HTML-AAM — Rule 1 of ARIA](https://www.w3.org/TR/html-aria/#rule1)
0 commit comments