On a sidenote, the small change in design to switch the option order makes it impossible to write an extension version which fits both with J3 and J4 design. Since the options will always be in the wrong order in one of the CMS version, no matter what you do.

I have raised the issue of the switcher many times to the developers of the template. I am not a fan at all.

Also see https://inclusive-components.design/toggle-button/

I really don't see any issue here. There's nothing to "figure out". You have a switcher, you click, is displays the text. It's the same concept as iOS and Android. I don't know why J3 displays "yes" on the left it's it's most certainly not the norm.

Whatever the norm and the rihts or wrongs of it It there is a very valid issue if this prevents an extension from working on J3 and J4

Switcher is optional, devs can keep their crappy things...
Core will utilise switcher

@dgt41 ok thats good then and oyu can ignore that issue

@C-Lodder I'm remembering correctly the approach here, right?

@brianteeman - how does it "prevent" an extension from working on J3 and J4?

I still hate the switcher though and I hope you read the link so that the crappy switcher is accessible

@brianteeman we can improve things, but we have to start from somewhere. IOS and Android is a good foundation IMHO

for a phone yes ;)

Explain why it's bad on a website. Remember we're even doing better by actually displaying text.

70% of web traffic is from phones, we should remember this metric!

@dgt41 traffic yes - development probably not

@C-Lodder if it is accessible then great but currently its not

So it's not fact that "Yes" is displayed on the right. AFAIR, I switched the ordering or the yes/no round for ALL parameters, so that "yes" is on the right (green), unless it's not the recommended setting.

I'll can add in some basics for accessibility such as aria attributes etc (I believe colour contrast is already done but will have to double check). Other than that, the "UX" and a11y team will need to give some input.

a11y: @armenos @ylahav
UX: @nonexistants

@bakual would know more about the issue of J3/J4 compatibility than me I was just taking him at his word on that

There's nothing to "figure out". You have a switcher, you click, is displays the text. It's the same concept as iOS and Android, however they do not display any text, whereas we do.

I just can tell from my personal experience when I first saw the switcher, and it was not clear at all. I had to toggle the switcher several times to understand if the text shows the active state or if it is the action that will get triggered when I press it or if it is the state when the switcher is on the right side.
It didn't help of course that the switcher is inversed when coming from J3 (as I pointed out above).
The greyed out text doesn't help as well.
The main thing that helped was a showon behavior that was attached to the switcher I tried. 😄

So don't tell me there is no issue and nothing to figure out. I told you there is one. I may not be 20 anymore but I'm not stupid and I certainly don't think I will be the only one having initial issues with that switcher.

As for iOS and Android, that's actually a wrong comparision. We're not building a mobile phone app here. It's a web site. And while a huge amount of web browsing today comes from mobile phones, managing websites is a completely other statistic (desktops are preferred there).

I don't know why J3 displays "yes" on the left it's it's most certainly not the norm.

First of all there is no "norm". iOS and Android do it this way but that doesn't make it a "norm". As I wrote it's much more important to have a good UX, whatever position you choose.
It think it was a decision from the UX group at that time. To me it's more logical to have it left as well (We also say "Yes/No" or "Show/Hide" toggles for a reason). The only thing that wasn't logical was that you had to write the values in descending order in the XML.
What I find highly unlogical however is that we switch the order with each major release. We should stick to one.

how does it "prevent" an extension from working on J3 and J4?

It doesn't prevent an extension from working. But it prevents it from following the UX of both CMS versions. While you can easily add the classes "btn-group btn-group-yesno switcher" which will look nice both in J3 and J4, the order can't be adjusted to fit the CMS version. It will be either wrong in J3 or J4.

One drawback of that switcher obviously is that it will only work with boolean selects. You can't have them for "male/female" or for parameters with more than two options. Do we need to use a dropdown select in those cases? That would be a step backwards imho. But that's not the point here, just something to consider as well.

I say the "norm" cause I had looked at a LOT of UI kits, both for mobile and web, and always say the green/active state on the right. I don't know of any system or UI kit that display it by default on the left.

I'm aware of the fields with more than 2 options. As it stands, the switcher can't be used for more than 2. In these cases I changed them to a select, but if someone has a different solution, PR's are welcome.

I just can tell from my personal experience when I first saw the switcher, and it was not clear at all. I had to toggle the switcher several times to understand if the text shows the active state or if it is the action that will get triggered when I press it or if it is the state when the switcher is on the right side.

If this is the case, what would you suggest changing about the switcher so that it's more clear?

If you read a bit about switcher and UX, all answers indicate that the order doesn't matter at all.
They also indicate that the UX and accessibility of such switchers usually are bad compared to a simple checkbox or radio. Some even say it's unintuitive to click/tap a switcher because you rather would move it.
UX can be improved by doing something like this:
Yes [o ] No
Colors of course help, but one should not rely on them alone.

I'm aware of the fields with more than 2 options. As it stands, the switcher can't be used for more than 2. In these cases I changed them to a select, but if someone has a different solution, PR's are welcome.

Keep in mind that we currently have a solution for toggles with more than two options as well as for "male/female" type ones (where you can't set a default). It works fine in J3 and even looked consistent.
The more I think about those switchers, the less I think they are actually an improvement over the current solution. They are less flexible, less clear, less accessible. What exactly was the reason to implement them beside trying to mimic an iOS/Android feel (which is a stupid reason as we're not a mobile phone app)?

Btw, just stumbled over what I think is a good a11y example for such a switcher (found on https://www.sbb.ch/en/home.html):

HTML Source looks like this:

There is a lot of hidden aria stuff the to make it accessible for screenreaders.

My 2c here, trying to fix the A11Y with a script that manipulates the DOM is the wrong (old way) approach, we should embrace custom elements here. Some examples:
https://www.webcomponents.org/element/arsnebula/nebula-switch/demo/demo/index.html
https://www.webcomponents.org/element/kcmr/liquid-switch
https://www.webcomponents.org/element/nuclei/material-toggle

Where do you see the use of a script for a11y?
The "aria-describedby="togglebutton_hiddentext_departure" references the ID of the hidden span a bit further down which contains the description of the action. That was the part I meant.
Plus the labels for each possible states (Dep and Arr in this case).
For a11y purposes we probably need to add something similar.

In the end, I'm still not convinced why we should even use them. Looks like there are only limitations compared to the current solution with buttons.

Closing since I did a PR to revert to the J3 buttons.
#15946