@aardrian if only there was proper advice on how to use these switches, rather than simply in place of a checkbox, which is wrong, imo.
It would be better if these switches were always in the middle, between two options, both labelled either side of it. Blob on left, option 1, blob on right, option 2. That's an entirely new input, not a pseudo-checkbox.
@sarajw@aardrian No, switches between two values can be super confusing and take up a lot of space. Plus you cannot assign two accessible names to one control in a meaningful way.
They are just switching something off or on, like a checkbox. It’s just another visual for a checkbox, not more, not less. Especially how iOS and also the Webkit implementation uses it: Light off/0 state = off, Light on/1 state = on.
Especially on the web they are often used for things that are not off/on, but that’s more a case of “web developers use a thing used for use case A and then apply it to use case B”. If you look at the use of switches in native iOS/macOS, it’s very consistent. That’s also why I think other platforms shouldn’t even bother implementing it. The support is mostly for web embeds in native apps in my opinion.
@sarajw@aardrian Yeah, I have one client that has a mix of native views and web views in the app, and when using accessibility features (more contrast, distinguish without color, …) the native switches adapted, the facsimiles in web view didn’t. So for that use case, it makes a lot of sense.
I think in other situations, checkboxes are generally a better choice.
@aardrian Even if it will exist in a future standard I'd prefer if it said DO NOT USE right there in the description, TBH. Its state is too ambiguous %)
@aardrian It's a nice addition, but the implementation seems a bit rushed. The control doesn't scale properly and visually breaks when changing the zoom level.
@aardrian I'm sure they had many reasons for proposing an attribute instead of a new input type, ranging from good(?), through esoteric, all the way to "this is bad but who cares". It seems weird to me, though; the fact that something is a switch is not an aspect of state. I am probably missing some context decided in 1993 that would make it seem reasonable.
@jscholes Safari already had code for ARIA switches, so glomming on to the first HTML proposal they like (assuming this was not filed by an Apple proxy) seems legit if it means another claim of “First!”
But yeah, could also be some leftover 1990s argument driving it too.
@aardrian@jscholes I believe the argument for using a separate attribute was to create good fallback to a regular checkbox, which I think is an important consideration.
I do think the boolean attribute is kind of a random inconsistent pattern, but on the other hand: there's nothing really consistent about how existing <input> elements work in HTML!
If it weren't for ARIA treating switches & checkboxes differently, I would have preferred to do this all with the CSS appearance property.
@AmeliaBR@jscholes The entire argument for that implements is in the issue I linked. We were talking (or I was) why Apple chose to treat this PR as if it was done.
I also agree the ARIA switch not allowing a mixed state is not only a confusing lack of parity but probably a lack of imagination on the part of the authors.
I may also be rambling from too many mumma and coffee breaks.
Add comment