Accessibility Issue - Switch Control Missing Associated Label

[parul-26]

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

1. Open the Carbon Design System documentation for the Toggle component.
2. Navigate to the "With Accessible Labels" section.
3. Inspect the toggle control with the switch role.
4. Observe that the control lacks an associated label, resulting in an accessibility violation.

Suggested Severity

None

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[philljenkins]

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.

[philljenkins]

In the screenshot with this issue, either the

• "Alerts and events" should be the programmatically associated and visible label for the switch, or the
• "If you disabled the card, it will not be displayed on the home page" as the label.

and open a separate new Carbon issue to fix No. 3 switch example:

• Fix label in No. 3 "Internal aria-label toggle" replacing aria-label with aria-labelledby as explained above.