Feature request: export `isInteractiveRole` and `isValidOwnedChild` utilities derived from existing role data

[johanrd]

Several ESLint a11y plugins independently derive the same two queries from aria-query's role data:

1. "Is this role interactive?" — filter concrete roles whose superClass chain includes widget:

• jsx-a11y: src/util/isInteractiveRole.js
• eslint-plugin-ember: lib/utils/interactive-roles.js
• vuejs-accessibility: src/utils/getInteractiveRoles.ts
• angular-eslint: get-interactive-element-role-schemas.ts
• lit-a11y: lib/utils/isInteractiveElement.js

All five independently implement the same superClass.some(chain => chain.includes('widget')) loop. Three of them (angular-eslint, lit-a11y, eslint-plugin-ember) also independently arrived at the same two special cases: exclude progressbar (its value is always readonly), include toolbar (supports aria-activedescendant in practice).

2. "Is role X a valid owned child of role Y?" — walk requiredOwnedElements transitively, closing over superClass inheritance (e.g. treegrid inherits row from grid and treeitem from tree):

• eslint-plugin-ember: same file as above (buildCompositeWidgetChildren)

The raw data is already in aria-query. The derivations are small but non-trivial (the transitive closure over superClass chains is the part each plugin gets slightly differently), and the special-case disagreements on progressbar/toolbar show the ecosystem hasn't converged.

Request

Would you consider exporting these as utilities from aria-query itself? Something like:

import { isInteractiveRole, isValidOwnedChild } from 'aria-query';

isInteractiveRole('button')              // true
isInteractiveRole('tooltip')             // false — document-structure role per §5.3.3
isValidOwnedChild('listbox', 'option')   // true
isValidOwnedChild('grid', 'gridcell')    // true — transitively via row
isValidOwnedChild('button', 'option')    // false

Cowritten by claude

[ljharb]

The first one seems highly motivated, since it's used by 5 plugins - i'd love to review a PR for that (please make very minimal use of LLMs for open source contributions, though)

The second is a bit less convincing. What is the reason only ember has need of it?

[johanrd]

Fair — isValidOwnedChild is specifically for the exception-list for a no-nested-interactive rule: without it, valid ARIA composite widgets (listbox > option, tablist > tab, grid > row > gridcell, etc.) get incorrectly flagged as nested interactive elements. The other plugins either don't have that rule or haven't implemented the composite-widget carve-out yet.

isInteractiveRole seems like a good start anyways.

[ljharb]

Can you help me understand why prohibiting nested interactive elements would be a problem?

[johanrd]

@ljharb Good question.

Why a no-nested-interactive rule in the first place?

The ember lint rule no-nested-interactive has been default in ember 'forever', and has helped me in some cases where I tried to shoehorn a small button (tooltip) inside a larger button, for instance. See the specs of a, button and label for instance:

Element	Spec quote
4.10.6 <button>	there must be no interactive content descendant and no descendant with the tabindex attribute specified
4.5.1 <a>	Transparent, but there must be no interactive content descendant, a element descendant, or descendant with the tabindex attribute specified.
4.10.6 <label>	Phrasing content, but with no descendant labelable form-associated elements unless it is the element's labeled control, and no descendant label elements.

Why no-nested-interactive needs exceptions?

WAI-ARIA §5.3.2 lists composite widget roles that are required to contain other widget-descended (interactive) roles:

• listbox: required owned elements — "an element using the option or group role" (https://www.w3.org/TR/wai-aria-1.2/#listbox)
• tablist: required owned elements — "a tab element, or an element with role tab" (https://www.w3.org/TR/wai-aria-1.2/#tablist)

Both option and tab descend from widget (§5.3.2 Widget Roles), so they are interactive by the same superClass derivation that produces INTERACTIVE_ROLES. The conflict: a blanket no-nested-interactive rule would flag <div role="listbox"><div role="option"> as invalid — but the ARIA spec requires exactly that nesting. isValidOwnedChild is the predicate that distinguishes "nested interactive that violates HTML content model" from "nested interactive that ARIA mandates"

[ljharb]

I see, thanks. Let's add both here (in 2 separate PRs - again, with minimal LLM usage please) and if you could also file a PR (or an issue) to add this rule to eslint-plugin-jsx-a11y, that'd be appreciated!