philljenkins
commented
1 month ago The 3rd toggle button is being flagged as missing a visible associated label:
- see generic input_label_visible.html Help page for the rule (same as "Learn more" link in Checker UI screenshot)
- "The input element does not have an associated visible label"
- "An input element must have an associated visible label"
Code from the DOM that is being flagged:
<div>
<div id="toggle-6-label" style="margin-block-end: 0.5rem;">Internal aria-label toggle</div>
<div class="cds--toggle">
<button aria-label="Internal aria-label toggle"
id="toggle-6" class="cds--toggle__button" role="switch" type="button" aria-checked="false"></button>
<div id="toggle-6_label" for="toggle-6" class="cds--toggle__label">
<div class="cds--toggle__appearance">
<div class="cds--toggle__switch"></div>
</div>
</div>
</div>
</div>No. 3 switch example
JAWS seems to correctly (?) reads the label (only once) for each toggle-button, including the 3rd switch, and whether "on" or "off".
[after further investigation Oct 7, 2024]
Is this the cause of the issue flagged by the Checker?
The button element text is empty:
<button aria-label="Internal aria-label toggle" id="toggle-6" class="cds--toggle__button" role="switch" type="button" aria-checked="true"></button>,
and because it has an internal aria-label, the label is not "visible", but spoken by JAWS;
and the external similar visible text label is in an earlier div, (outside the button element) (not a container or parent, correct? Yes):
<div id="toggle-6-label" style="margin-block-end: 0.5rem;">Internal aria-label toggle</div>
Is that triggering the rule input_label_visible even thought JAWS seems to read it as if it's correct? Yes.
I believe that although JAWS is reading the internal aria-label, that just happens (accidentally or on purpose) to match the visible label in the earlier div, but there is no programatic association between the earlier div and the <button element, so it fails the rule.
I confirmed this could be fixed, and, pass the Checker rule by replacing the internal
aria-label=="Internal aria-label toggle" with
aria-labelledby="togle-6-label" from the earlier div.
However, it kind of defeats this "bad" example of an internal "so-called-invisible" ARIA label, if that is what the Carbon switch No. 3 is trying to show. That is the clue I get from the label itself "Internal aria-label toggle". The switch label needs to be visible and programmatically associated with the switch to assistive tech, such as voice command & control, otherwise the user+AT doesn't know how to refer to the switch if it doesn't have an associated visible label by which to call it.
It's not a Checker issue in my opinion, but a "bad" Carbon example. Carbon would have to come up with a better accessible example on when to use an "internal aria-label", if ever for switches.
There are a couple examples where "invisible" labels are allowed, so not always a "Violation", which is why this input_label_visible rule is "Needs review". See the Equal Access Toolkit - Designer guidance for Input labels for when an invisible label is acceptable. A 2 or 3 part phone number is an example, a switch is not an example.
Package
@carbon/react
Browser
Chrome
Operating System
MacOS
Package version
1.40.0
React version
18.2.0
Automated testing tool and ruleset
IBM Equal Access Accessibility Checker
Assistive technology
No response
Description
the error we are getting :
In the Carbon Design System, the toggle control with the switch role is missing an associated label. This causes a accessibility violation, as it makes the control unusable for screen reader users.
WCAG 2.1 Violation
No response
Reproduction/example
Component: Toggle (With Accessible Labels) URL:https://react.carbondesignsystem.com/?path=/story/components-toggle--with-accessible-labels
Steps to reproduce
Suggested Severity
None
Code of Conduct