Closed hans2103 closed 2 weeks ago
adding role="option"
to the elements that use aria-selected="true"
will solve the issue.
while native HTML option elements that are descendants of a select can only be set as being selected, elements with an explicit option role can not only allow the equivalent aria-selected, but also the aria-checked attribute, supporting widgets/constructs that go beyond the capabilities of a native select element.
source: https://www.w3.org/TR/html-aria/#aria-semantics-that-extend-and-diverge-from-html
@hans2103 thanks, I've merged that into my fork which will be pushed to my v11.0.0 PR after the weekend. I'm still working through some of the e2e tests, so main
on my fork may be broken.
The diff for this change isn't complicated but I only have the ability to merge other people's PRs not my own :(
It ended up touching a few more bits, but lighthouse accessibility score is reporting between 92 to 100 depending on the exact test page. Well better than the previous 72 or lower.
Obviously no substitute for real testing with a screen-reader.
One of the changes is to apply aria-label
by extracting a matching <label for>
which references the backing element's id.
Describe the bug While performing accessibility check using Lighthouse I get the following message in the results:
To Reproduce Steps to reproduce the behavior:
Expected behavior Expecting [aria-*] attributes to match their roles
Screenshots
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context Add any other context about the problem here.