[Feature]: getByRole Support of summary Elements

[ITenthusiasm]

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.

[cmorten]

R.E.

Another alternative is to do nothing and hope that the spec comes up with a true implicit role

See w3c/html-aam#345 (comment). Feels like there is some traction in this space.

[ITenthusiasm]

Oh wow. That's a really helpful link. Yeah it looks like it wouldn't be so easy to move forward with something like this then. I guess in the meantime we'd need to stick to getByText("SUMMARY_TEXT", { selector: "details > summary" })?

[MatanBobi]

Hi @ITenthusiasm! Thanks for taking the time to open this issue.
This is going to be a tough one. We're using aria-query for the implicit role mappings and they follow the spec only. We don't want to have code which is not spec compliant because it will open up a new dependency for us, so I guess that this is better opened in aria-query.

[ITenthusiasm]

@MatanBobi Makes sense! Thanks for reviewing the issue and providing that background! 🙏🏾 It makes sense to stay close to the spec and avoid extra dependencies. I'll reach out to them soon.

[ITenthusiasm]

@MatanBobi Created A11yance/aria-query#546. Leaving a note here as a reference. @cmorten's link is also worth keeping track of.

[weilbith]

I've a similar issue, but for me it starts with querying for the <details> element already. According to the specification this has an explicit role of group. As a <details> element can also have the name attribute, I thought this query should work: getByRole("group", { name: "my-name" }). But it doesn't (also without the name).
So I guess this should actually work. Shouldn't it?

[MatanBobi]

@weilbith details has an implicit role of group and not explicit, explicit means you add it on your own.
The name attribute is not the accessible name which is used to filter in getByRole("group", { name: "my-name" }). The group role supports name from author which means you'll need to add aria-label or aria-labelledby:
https://www.w3.org/TR/wai-aria-1.2/#namefromauthor

[weilbith]

Thank you very much for the quick answer!
You're absolutely right. I mixed that up, sorry. 🙈
So I guess I'm stuck on the same issue to properly select the summary of the details. 😕