Open wkeese opened 1 month ago
I updated the title and description upon realizing this applies to anything with a Tooltip
.
Luckily at least on Chrome, the accessibility tree takes the label from the tooltip node even though it's aria-hidden
.
But it does break https://testing-library.com/, specifically if I have this Carbon CSS:
.cds--popover-content {
display: none;
}
.cds--popover--open > .cds--popover > .cds--popover-content {
display: block;
}
Then this statement will fail:
screen.getByRole("button", { name: "Close the window" })
Package
@carbon/react
Browser
Chrome
Operating System
MacOS
Package version
1.68
React version
18
Automated testing tool and ruleset
accessibility-checker
Assistive technology
No response
Description
Apparently anything with a Tooltip ends up with both an
aria-label
and anaria-labelledby
.You can see it for example on the Close button of a modal:
Also, Pagination's next and previous buttons:
This is wrong, see https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label, which says:
But it's worse than that because the
aria-labelledby
points to a node (the tooltip) that hasaria-hidden=true
:I think the
aria-hidden
goes away when you focus the button, but it still seems weird (and wrong) that the button sort-of doesn't have a label until you focus it.You've probably talked about this before, but why not use
aria-describedby
instead?WCAG 2.1 Violation
Probably
Reproduction/example
https://react.carbondesignsystem.com/?path=/story/components-pagination--default
Steps to reproduce
Just navigate that that page and look at the DOM.
Suggested Severity
None
Code of Conduct