Slide-toggle should use role="switch"

[stevenyxu]

Please describe the feature you would like to request.

mat-slide-toggle should expose an input that causes it to present button and aria-pressed semantics rather than checkbox and aria-checked.

What is the use-case or motivation for this proposal?

The ARIA implementation of mat-checkbox and mat-button-toggle are great. mat-checkbox is a standard checkbox with aria-checked. mat-button-toggle is a standard button with aria-pressed. The usage guidelines are pretty clear: use checkbox when the change is pending form submission and toggle button when the change is effective immediately.

mat-slide-toggle sits in the middle ground in terms of apparent semantics and can plausibly be used in both situations. Currently it only presents as a checkbox. Maybe we could keep this as a default option and add an input that uses button with aria-pressed semantics.

WAI guidelines for toggle buttons: https://www.w3.org/TR/wai-aria-practices/#button

Toggle button: A two-state button that can be either off (not pressed) or on (pressed). To tell assistive technologies that a button is a toggle button, specify a value for the attribute aria-pressed. For example, a button labeled mute in an audio player could indicate that sound is muted by setting the pressed state true. Important: it is critical the label on a toggle does not change when its state changes. In this example, when the pressed state is true, the label remains "Mute" so a screen reader would say something like "Mute toggle button pressed". Alternatively, if the design were to call for the button label to change from "Mute" to "Unmute," the aria-pressed attribute would not be needed.

Is there anything else we should know?

I looked at google3 examples of mat-slide-toggle especially in Cloud Console, and it's pretty split down the middle whether it's a part of a form or effectively a button with immediate action.

[devversion]

Thanks for the issue. That's a great point. I think it would make sense allowing users to opt-in for button and aria-pressed semantics.

We just need to see how we are going to implement this with a reasonable option name, and without changing the underlying logic too much. Currently the state management of the slide-toggle depends on the state of the underlying checkbox element.

[devversion]

cc. @jelbourn do you think that this would be reasonable to implement?

[devversion]

Something I wanted to add as well. Even though it might not be the intended use, people often use <mat-checkbox> in combination with [(ngModel)]. This means that the checkbox can be incorrectly used like a button where the change is effective immediately. Similarly the slide-toggle can be used in two ways.

[stevenyxu]

Thanks for looking into this. I think situationally people will always want to use all three controls in both ways (effective immediately and pending form submission), regardless of whether the UX is clear.

I think being attached to an [(ngModel)] does not necessarily mean that it's effectively immediately. If the model binding merely updates an in-memory model with no side-effects and doesn't do anything until form submission (e.g., checkbox in form) or further action (e.g., checkboxes to select rows on a table) it doesn't count as "immediate" and the checkbox is still appropriate.

If it's the case that mat-slide-toggle is tied to the role semantics of mat-checkbox, it might not be a bad idea to expose the same sort of option within checkbox, though with the opposite default setting. I struggle to think of a case where a checkbox should be used as a semantic button, but it may not be the worst thing to have available.

[devversion]

I think situationally people will always want to use all three controls in both ways (effective immediately and pending form submission), regardless of whether the UX is clear.

Definitely. That's why I personally agree with providing an option instead of enforcing one of the possible use-cases 👍

I think being attached to an [(ngModel)] does not necessarily mean that it's effectively immediately.

Agreed. I was just providing an example of how people could use the checkbox in an immediate way.

[jelbourn]

I talked w/ our Google a11y expert on this, and they explained that this component should use the new ARIA 1.1 role="switch" for this component. At this point it is actually supported well-enough by screen-readers that it should be good to use.