fix: The <form> element now always exposes the role "form"

[julienw]

This has been changed in the ARIA spec in
w3c/html-aria#402.

See also testing-library/dom-testing-library#1293

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[jlp-craigmorten]

@julienw see also scripts/roles.json which needs an update (and if done first actually allows for the code to be generated using node ./scripts/breakUpAriaJSON.js)

[julienw]

I see there's "superClass": ["landmark"] below, but I'm not sure about that since the form shouldn't be exposed as a landmark region without an accessible name now. Do you have a suggestion about that?

[jlp-craigmorten]

Until w3c/aria#1764 is resolved I fear it is perhaps ambiguous as to what the expectation is here?

Even once that is resolved, if it transpires that constraints are needed on the superclass then the data structure as it currently stands isn't expressive enough for this afaik as it stands and we'd need a (potentially breaking) change to accomodate that conditional logic. Depending on use-cases for this library, doing such may be YAGNI?

I'm not confident/familiar enough with the concepts in specs to understand if the superclass role in ARIA is relevant to the landmark exposure (or lack of) described in the AAM specs? We might be conflating an inheritance model here with the expectations on what mapping is used by Accessibility APIs (would need to understand if that Accessibility API exposure is driven by the inheritance or not).

Would need someone like @scottaohara (apologies for the out of the blue ping) to help clarify I expect.

[aloisklink]

[...] if it transpires that constraints are needed on the superclass then the data structure as it currently stands isn't expressive enough for this afaik as it stands and we'd need a (potentially breaking) change to accomodate that conditional logic.

Constraints on the superclass also affects the separator role, which either has a superclass of widget or structure, depending on whether it is focusable or not, see #587 (thanks @cmorten for linking this together)

Depending on use-cases for this library, doing such may be YAGNI?

This causes libraries like eslint-plugin-jsx-a11y and Svelte (which rely on this library to check if a role has the widget superclass, to check whether something is interactive/non-interactive) to throw spurious warnings like:

A11y: noninteractive element cannot have nonnegative tabIndex value
A11y: Non-interactive element <div> should not be assigned mouse or keyboard event listeners.

But, it does seem like quite a lot of effort to fix here! It's probably easier to fix on the WAI-ARIA side of things, see w3c/aria#1348