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.
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 recommendedgetByRolequery.If possible, it would be great if
getByRolecould support<summary>.Suggested Implementation:
According to MDN, the implicit ARIA role is
button. So a simple solution could be to allowsummaryelements to be discoverable bygetByRole("button"). However, one thing to keep in mind is that according to the spec:When I tested with VoiceOver, the
summaryelement seemed to be identified as a unique kind of button that was related to thegroupcreated by thedetailselement. 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
summaryelements are newly discoverable by usinggetByRole.