Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Redesign the Switch #5500
Here's what it looks like:
Here's what it looks like in Windows high contrast mode:
There are a number of benefits to removing the explicit text label on the right, in favor of the two 1/0 icons overlaid:
This has been tested on Chrome, Firefox, Safari, IE11 and Edge and high contrast mode.
I'm sorry I understand the layout gets simpler but removing the visible text automatically makes this toggles not accessible. We've discussed this point a few times before in a few issues and I thought there was consensus...
Switches should always show On/Off label
In that issue some consensus was reached, see #2146 (comment)
As I see it, there's a design problem. This problem can't bs solved at the expenses of reduced or absent accessibility. I'd strongly recommend to try a different solution.
There are a number of options mentioned in other issues. One of them is to place the text below the toggle; a smaller (not too small) font-size could help.
So, I do recall that discussion. However since then, translation issues have come to light, and in situations where a group that includes a label, a switch, and help text (see #5498), showing the On/Off label below the switch doesn't work.
This is the same as iOS does: http://osxdaily.com/2014/04/15/ios-settings-switch-on-off-labels/ — you might find that insufficient, but given that it's working for mobile users, I would argue that it's a vote that this unified switch design can be sufficient without an added label.
Universal symbols don't exist. Different cultures, cognitive impairments, low vision... should I continue?
Saying it's the same as iOS does it's not an argument. That's a mobile UI (and it's not accessible).
I do think this is totally insufficient from an accessibility perspective. I'd also argue that the root cause of the issue is just about aesthetics and the will to introduce some "pretty looking" controls. I don't see any particular advantage in introducing these toggles, they do more harm than good, while a native checkbox would do its job.
All the previous conversations about these controls were already in the spirit of finding a trade-off between design and accessibility and, from the a11y side, we've already done a lot of compromises. Now, completely removing the text is a no-go as there's no textual indication of the toggle state.
while they've deprecated the previous version with the text “on” and “off” they also state:
So they clearly warn there must be a textual inication of the state. And with good reasons.
There are a few places where we pass down props which are created on the fly in the same component. I can refactor to use an object method instead. We never measured if this has a negative impact on the performance of the application.