Custom radios / checkboxes

[robinwhittleton]

This requires no change to the existing HTML: the custom inputs are built using pseudoelements. In a no-JS / no-CSS / IE8 scenario it falls back to standard inputs. To style the radio and checkboxes differently a class is needed on the label - this is automatically added by the new SelectionButton JS.

This is partially based on Verify’s styles, and updates a design by @timpaul and @joelanman inspired by observations from user research and lots of requests from @cjforms. The inputs are sized to match the height of text inputs.

Tested on:

• IE 7-11
• Edge 14
• OS X Firefox 48
• OS X Chrome 51
• OS X Safari 9
• iOS Safari 5.0 - 9.1
• Android 4.4+ Chrome

Android Browser on BrowserStack’s Nexus 4 (4.2) is massively unresponsive and doesn’t seem to let you click on the radios most of the time. It will need to be tested on a real device.

Would absolutely love any feedback.

• Base implementation + testing
• Check that this works with click events in Selenium (testing in verify indicated possible problems)
• Make it use currentColor for compatibility with custom colour themes
• Make the pseudo-elements permanent and just repaint the background colour on state change
• Add a translucent hover state
• Test in old Android devices
• Fix general problems with Dragon Naturally Speaking 13 on IE11 (Dragon 12.5 is fine)
• Padding no longer exists after legends - investigate recommended changes

[joelanman]

Tim Paul and me :)

[robinwhittleton]

Oops! Fixed.

[paulmsmith]

Nice

[NickColley]

Might be worth marking as [Do not merge] since it relies on the upstream addition to selection buttons?

Be good to test this out on some real devices, looks good.

[NickColley]

Some interesting information around touch sizes http://www.lukew.com/ff/entry.asp?1085 , might be relevant :P

[robinwhittleton]

Interesting research! The actual input has increased in height from 29px to 37px, but as we’ve removed the grey background it no longer needs the padding which means that the overall height of the hit area has gone down from 60px to 37px. As long as people are still trying to press on the control maybe that’s not a problem though.

[joelanman]

this work comes from user research that shows that in general people don't know the grey area is the hit box. so while the actual hit box is reduced, the perceived hit box is increased.

also worth noting that, at least in Chrome on OSX, our current radios aren't actually 29px (perceived)

[robinwhittleton]

Just remembered, I also want to get @cfq / @accessiblewebuk / @aduggin’s seal of approval on this before we merge, or at least before we do a release.

[aduggin]

@robinwhittleton Can you make a rendered version available on a public url (for example, in the sandbox) so we can get it fully tested?

[joelanman]

Why does it need to fall back to default inputs in a no js situation?

[robinwhittleton]

<input /> is an empty element: it can’t have pseudo-elements because there is text content for a ::before to be before or an ::after to be after. Therefore if we want to keep the same HTML structure we need to attach out pseudo-elements to the parent label. That poses a problem – we can’t style the parent based on child state (currently) so we need to base our pseudo-element styles on the classes that SelectionButtons applies. If we don’t have these classes then the fake inputs will be able to display their selected state, so we need to make sure that they don’t show up in the absence of JavaScript.

[cjforms]

Based on a design by @timpaul and @joelanman, (and as @joelanman pointed out) inspired by observations from user research. Plus lots of requests from me.

[edwardhorsford]

Is this deployed anywhere we can try?

What do these do on hover?
What do these look like with focus?

Any thoughts on the below hover effect? (stolen from @selfthinker)

[robinwhittleton]

Is this deployed anywhere we can try?

Not yet.

What do these do on hover?

No change. I like @selfthinker’s idea. What would you want to do with checkbox hover states?

What do these look like with focus?

Due to removal of padding I went for outline of the element (square with checkboxes):

[edwardhorsford]

@robinwhittleton It's something I'd want to try in user research. I suspect you could do a greyed out tick on hover. I think once the radio or checkbox has been checked, hovering over it should not show the greyed symbol.

An alternate would be to show a hover effect that is not the same as the tick or dot and could work whether the control was selected or not. Something like changing the white ring for a grey ring, or grey inner-stroke.

---

Seperately - how do these work for people who use css to adjust contrast / change colours?

[robinwhittleton]

It’s worth having the conversation about contrast issues, but my gut feeling is that browser-default checkboxes and radios already don’t respond to setting user colours?

[edwardhorsford]

@robinwhittleton My worry is especially about something like this happening:

Where the controls themselves disappear rather than being the wrong style.

Chatting with @NickColley on Slack, it sounds like we may have a solution?

[NickColley]

The idea I put forward on slack was to remove the white background from the input and allow the colour to be defined by the text color of the label.

In the above examples the container I set the background-color and color and you can see the changes reflect properly when using currentColor and removing the background from the input.

Might be some edge cases I've not thought about though..

[robinwhittleton]

Hmm. That generally works. I think on Verify start page we’d want to keep the white background though.

But that can be an override for specific situations.

[edwardhorsford]

@robinwhittleton The current live verify radios do not work if the user has custom colours set (using firefox). Clicking on the option does nothing (visually). Where can I raise this?

[robinwhittleton]

New issue on verify-frontend? The fix might be to complete this PR though and merge that in.

[tombye]

This is ace, thanks Robin. Minor question: is the js-enabled class needed in the selectors?

I might be missing something but I think the styles can all be based off the selection-button-radio and selection-button-checkbox classes which are only applied if the JS for that runs anyway. If that's the case it would be nice to hang these styles off that rather than being dependant on the user having JS at all.

[robinwhittleton]

For the most part that wouldn’t be a problem, but imagine this situation:

1. Developer copies HTML from an existing service by opening devtools and right-click / Copy HTML on a node.
2. Developer then pastes that rendered HTML (which includes selection-button-radio) into a new place and changes the name and text of the radio and label.
3. Developer doesn’t notice any difference as the JS is applying that class anyway.
4. User without JS finds a custom radio button and no way of selecting it.

Obviously good developers should test with JS disabled, but it’s easy for something to slip through. Wrapping all of this in a .js-enabled is being a little more defensive.

[tombye]

Makes sense.

[gemmaleigh]

Thanks for all your work on this @robinwhittleton and to everyone else who contributed and offered advice.

We'll release an update to govuk_elements for custom radio buttons and checkboxes today and update the govuk_prototype_kit to include them too.