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.