[Feature]: `getByRole` Support of `summary` Elements

Desired Feature

The <summary> -- together with the <details> element -- plays an incredibly important role in supporting "Accordion Components" natively -- and without the need for JS! They are exposed to the accessibility tree and discoverable for Screen Readers (tested with Voice Over in FireFox/Safari/Chrome on MacOS). However, this important element is not currently discoverable for developers using the recommended getByRole query.

If possible, it would be great if getByRole could support <summary>.

Suggested Implementation:

According to MDN, the implicit ARIA role is button. So a simple solution could be to allow summary elements to be discoverable by getByRole("button"). However, one thing to keep in mind is that according to the spec:

Many, but not all, user agents expose the summary element with an implicit ARIA role=button.

When I tested with VoiceOver, the summary element seemed to be identified as a unique kind of button that was related to the group created by the details element. Based on other people's previous experiences, other Screen Readers seem to do something similar. So the hope is that this would be a reasonable change.

Alternatives

Another alternative is to do nothing and hope that the spec comes up with a true implicit role that isn't dictated by User Agents like popular Screen Readers. However, it's not clear how long that would take (or if that would ever happen).

Teachability, Documentation, Adoption, Migration Strategy:

The documentation probably would not need an update. More than likely, the Changelog could just mention that summary elements are newly discoverable by using getByRole.

Start by tracing the getByRole implementation and its role mapping for HTML elements. Check how summary and details are represented in the accessibility-related tests, then verify that summary elements are discoverable through getByRole("button") without changing unrelated role behavior.