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:
<label>
<Description />
<Toggle />
</label>
^ 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:
I think iconography would make a bit more sense here (✔︎ vs ✘) because of localization - in some languages "YES" and "NO" can be longer affecting the layout of a toggle element.
I'm not sure (I genuinely don't know that and need to google a bit) if "YES" and "NO" should be part of a <label> element itself as I always thought <label>s are meant to describe the field purpose and not its value. But again - that's something I'd have to verify :).
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
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 :)