Switch component is not visible in high contrast mode

[dominoweir]

Steps to reproduce

Link to live example: (required)

Every single switch on https://mui.com/material-ui/react-switch/

Steps:

1. Visit the link above in a chrome browser
2. In chrome dev tools, open the "rendering" tab in the console drawer and scroll down to Emulate CSS media feature forced-colors. Set it to forced-colors: active
3. Note that the switches are not visible in any demo on the docs page.

Current behavior

Switches are not visible, although the pointer cursor does show when you hover on them

Expected behavior

Switches should be visible when forced colors mode is turned on

Context

Trying to fix some accessibility issues in high contrast mode and although I might be able to override the styles on my own, it would be better for this to work out of the box.

Your environment

Please note that although I'm using v5 right now, this issue is reproducible on mui.com using the latest version option available.

npx @mui/envinfo

    System:
    OS: Linux 6.7 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
  Binaries:
    Node: 20.16.0 - /usr/local/bin/node
    npm: 10.8.1 - /usr/local/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 128.0.6613.84
  npmPackages:
    @emotion/react: ^11.13.0 => 11.13.0 
    @emotion/styled: ^11.13.0 => 11.13.0 
    @mui/base:  5.0.0-beta.31 
    @mui/core-downloads-tracker:  5.15.4 
    @mui/icons-material: ^5.15.4 => 5.15.4 
    @mui/material: ^5.15.4 => 5.15.4 
    @mui/private-theming:  5.15.4 
    @mui/styled-engine:  5.15.4 
    @mui/styled-engine-sc: ^5.11.11 => 5.11.11 
    @mui/system:  5.15.4 
    @mui/types:  7.2.13 
    @mui/utils:  5.15.4 
    @mui/x-data-grid:  6.18.7 
    @mui/x-data-grid-pro: ^6.18.7 => 6.18.7 
    @mui/x-date-pickers:  6.19.0 
    @mui/x-date-pickers-pro: ^6.19.0 => 6.19.0 
    @mui/x-license-pro: ^6.10.2 => 6.10.2 
    @types/react: ^18.3.1 => 18.3.3 
    react: ^18.3.1 => 18.3.1 
    react-dom: ^18.3.1 => 18.3.1 
    styled-components: ^6.1.12 => 6.1.12 
    typescript: ^5.5.3 => 5.5.3 

Search keywords: forced-color, forced color

[dominoweir]

For anyone who might be looking for a workaround, I had a hard time overriding background colors so instead I added border colors to both the knob and track for the switch:

[oliviertassinari]

I haven't seen a lot of high-contrast issue reports through the years, I'm actually surprised.

Recently, I had a fun time reading https://polypane.app/blog/forced-colors-explained-a-practical-guide/.

[siriwatknp]

Mark this to consider in v7. This is a use case where a default transparent border is helpful.

[oliviertassinari]

Interesting data from the link above https://polypane.app/blog/forced-colors-explained-a-practical-guide/:

In terms of numbers, Microsoft states that 4% of Windows users use High Contrast mode. In the WebAIM low vision survey, 50% of low vision users indicate they used the mode but of course, that is likely a very self-selecting group of savvy users.

but it can also be a lot of work: https://youtu.be/XYjH_oQ3llg?si=Zcsnb4LBMY7dDjEG&t=792. So to balance the priorities, I could see this fixed by the community.

[dominoweir]

Assuming you're okay with the simple fix of adding a border on the track and knob, that's something I could potentially do-
@oliviertassinari any docs out there on how to make community contributions?

[DiegoAndai]

@dominoweir here's our contributing guide: https://github.com/mui/material-ui/blob/master/CONTRIBUTING.md

If you open a PR, please add myself and @zanivan as reviewers 😊