Intro
Toggle is a TRUE/FALSE switch that looks like a... switch... Similar control you can find in your smartphone settings probably.
U...
For further actions, you may consider blocking this person and/or reporting abuse
If you want, you can achieve the same using only the native input element
Oh this is lovely proof of concept! I think it needs a bit polishing (I’m checking it on my mobile and there’s something off with proportions but I’m pretty sure it’s easily fixable) but I love it! The simpler, the better as long as it’s bullet proof 👌 Anyway, I may steal this one from you:)
that issue is for sure related to the aspect-ratio. Replace it with the classic width/height and it should work fine ;)
Why would you want to avoid using a label? It's the right element to use when you want to... label something, and it makes no sense to have a switch without context.
Interestingly, I got tasked with making a toggle like this recently, and the UX called for it to be "default on". The design first came through with it active on when the switch was to the left, which I had to question, and got changed to the more conventional right-side-on pattern.
The front-end person building the other components on the project happens to be colourblind, and they saw the original as "it's on the left, and it's one shade of grey-brown, and the grey-brown changes slightly when you move it right". They would have used the control wrong in the real world.
My partner struggles with left vs right for meaning (and she's always telling me "take the next left, no the other left" when we're driving somewhere...) and I have another friend who's dyslexic and it manifests in not associating direction with intent like that.
We got a redesign, and I can't easily show you the CSS because I'd have to unpick it all, but that's irrelevant for the purposes of this comment. Here's a screenie:
It uses a label element and has clear, contextually-appropriate states (in this case "yes" and "no", but they could be changed depending on the proposition the label makes).
First of all, thank you for this feedback, I really appreciate it! Let me address some thing below:
As I mentioned at the end of my post: I do think all controls should have label associated - no doubts about that. But this whole thing came up because we didn't want descriptive label to be part of the control itself in our design system. We try our base components to be as low-level as possible. It's just how our design system is built. And that's because in our designs we use toggles in few different visual configurations: sometimes they are above label, sometimes they are below label, sometimes they are on the left of it and sometimes on the right.. Sometimes labels are super descriptive with additional helper texts and sometimes they are very short. Your example above with "Auto-renew" layout is just one of the possible use cases.
So on one hand we could have this (which I believe is your approach from screenshot):
^ but again, we don't want our design system components to define the layout of entire element because then we would need that "Auto-renew" to be part of the component itself (so the entire
<label>would have to be a component. Hence this approach would be very limiting to us.Instead we prefer to be more granular:
^ so the
<Description />can be anything we want and at the same time we have full control over<Toggle />placement and so the general<label>'s layout.HOWEVER you also brought up very good point about folks with some sighting issues and other disabilities and also displaying the value "YES/NO". I do think it's important to add that to the UI control but:
<label>element itself as I always thought<label>sare meant to describe the field purpose and not its value. But again - that's something I'd have to verify :).I think I misunderstood when you said:
To mean that you knew what you should do and were choosing not to, rather than that you would wrap the whole low-level component in a label.
And yes, we'd need to do localisation depending on use-case :)
Even better is to use
aria-role="switch"— not only does it tell screen readers that the checkbox is more specifically one that resembles a switch*, but it also gives you an extra way to style checkboxes without having to use a seperate class! We used it for Adapt UI's switch element, as shown at the bottom of our demo.Additionally, it's possible to style the
inputelement itself instead of having to rely on an adjacent element to render the design of the switch —appearance: none;always comes in handy!*Not to mention that the difference between a switch and a checkbox in terms of UX standards is that when a switch is changed, its state is immediately applied, but when a checkbox is changed, it usually requires confirmation using a seperate button.
If I understand this correctly, it would require JS to change the
aria-checkedvalue (which is required when usingrole="switch"and btw that seems to be missing in the Adapt UI Demo you linked to) and that was a constraint in my example.Good point — that's definitely a thing to add to our library! Having tested our demo in a few screen readers, they seem to still be okay with using checkboxes'
checkedvalue with the role, but it's a good idea to add the extra attribute (with JS or course) for assistive technologies that aren't as good at detecting that. Thanks for the advice!I would assume from the docs that the
aria-checkedattribute is used mainly so screen readers can tell the user when a checkbox changes state on its own (without interaction), which would make sense!Great writeup
This is also a good addition: codepen.io/KittyGiraudel/pen/xxgrPvg
Nice explaining!
Very helpful ! Thank you for this !