https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-radios-and-checkboxes-on-gov-uk/

We've updated the radios and checkboxes on GOV.UK

Last week we updated the styles for radio buttons and checkboxes on GOV.UK. This post explains why we’ve done this.

Our old radios and checkboxes looked like this:

Image of the old style checkboxes and radios where the labels have a grey background

The new ones look like this:

Image of the new style radios and checkboxes, with no grey background and larger controls

We’ve removed the grey boxes and increased the size of the controls. To understand why we’ve done this it helps to know what problem we were trying to solve with the grey boxes.

The problem

Early in the development of GOV.UK we observed in research how a majority of users would click on radio button or checkbox controls rather than on their labels, despite the fact that the labels are much bigger and therefore easier to click (see Fitt's Law).

Image showing a checkbox control and label

We reasoned that this was because users didn’t know whether or not they could click on the labels. Many websites don’t let you click on labels, so choosing to always click on the control is perfectly rational user behaviour.

The solution

Iteration 1 - grey boxes

First we thought we’d try to make it really obvious that you could click our labels, so we coloured them grey and made them respond to the mouse hovering over them.

We thought this would work, so we rolled out the design across services on GOV.UK. We saw again and again though in lab research that most users still clicked on the controls.

Iteration 2 - bigger controls

In our next iteration we decided to support the existing user behaviour, so we increased the size of the controls to make them easier to click.

Unfortunately it turns out that native browser support for bigger radios and checkboxes is very patchy. Nearly half the browsers we tested didn’t support these bigger controls.

Still, we rolled out the change for those that did and raised bug reports for those that didn’t.

Iteration 3 - custom controls

In our latest iteration we’ve replaced the native browser controls with custom ones, which all our supported browsers will get.

We’ve also removed the grey background, as it did not have the effect on user behaviour that it was intended to.

The new controls are more in keeping with the rest of GOV.UK and are the same height as our text fields, which improves the vertical rhythm on form pages and allows for better horizontal alignment of form fields.

The results

The new styles have been piloted in a number of services, including high-volume ones like GOV.UK Verify. So far they’ve tested really well. In research, people of all confidence levels are clicking these controls quickly and easily.

The code has been tested extensively and works across the full range of supported browsers, even if the user has customised their colour scheme. You can read Robin Whittleton's post about how we implemented the styles for more information.

We’ll continue to monitor them though - if you’re implementing these styles in your service then we’d be very keen to hear either way how they’re performing.

How to get the new styles

Designers can get the new styles by using version 5.0.0 or up of the GOV.UK Prototype Kit. Developers will find them in version 2.2.0 or up of GOV.UK Elements.

Thanks

We don’t make global changes to GOV.UK styles lightly. This has been the culmination of a lot of work by a lot of people, but especially Joe Lanman, Ed Horsford, Caroline Jarrett and Robin Whittleton.

Thanks also to the service teams in DWP and NHS who agreed to pilot early versions of these styles in their prototypes and services.

66 comments

  1. Comment by H.Lippisch posted on

    Change the size by all means, but you also changed their appearance. They're flat, and no longer look like radio buttons or check boxes. What was the rationale for that?

    Reply
    • Replies to H.Lippisch>

      Comment by Tim Paul posted on

      We've not observed users having any issues with the custom styles in research. They're actually very similar to the native styles for later versions of Internet Explorer and Edge on Windows machines, so they'll be familiar to lots of people.

      Reply
  2. Comment by Adam posted on

    Are users still clicking the radio/checkbox instead of the label on the new version?

    Reply
    • Replies to Adam>

      Comment by Tim Paul posted on

      Yes people still click the controls, but many will find it easier now that they're larger across all browsers.

      Reply
      • Replies to Tim Paul>

        Comment by David Waterman posted on

        Are there any form elements for which users will tend to click on the label? When I read your rationale for removing the grey around the label (and control), my first thought was along the lines of - you're trying to turn them into buttons, to why not actually just do that so it is obvious to users that they can click it all. Perhaps you can even remove the control until it is clicked - ie just add a 'tick' to the label.

        Reply
        • Replies to David Waterman>

          Comment by Tim Paul posted on

          Hi David. This is actually something we tried on the Claim Carer's Allowance service. It did work in most cases - people clicked the labels. However it also created a few new problems - how to distinguish between radios and checkboxes for example. In the end we decided to go with the approach described here.

          Reply
        • Replies to David Waterman>

          Comment by Joe Lanman posted on

          We also tried removing the input completely on Verify. The issue was people were confused and worried that clicking might take them away from the page, as a button would normally do, as opposed to selecting an answer, and allow them to interact with the rest of the page.

          Reply
  3. Comment by gavin posted on

    Are services going for assessment from now on going to be expected to use these new controls? Would research showing that they are not working for the particular users be take into account?

    Reply
    • Replies to gavin>

      Comment by Tim Paul posted on

      Hi Gavin, another good question. If a team can show that they have a plan for updating their styles within a reasonable time period then that would satisfy an assessment panel. I'd hope that all services would try to refresh their styles shortly before coming for an assessment anyway. Point 5 of the standard is probably most relevant here.

      To answer your second question, we'll always consider evidence coming in from service teams - you're a crucial part of the feedback loop. But a service assessment is probably not the best place to have that conversation - better to publish your findings and tell us on the usual channels (Slack, mailing lists, Hackpad, Github etc.)

      Reply
  4. Comment by Mike posted on

    Does your pattern include styles for disabled checkboxes and radios, and was that tested?

    Reply
    • Replies to Mike>

      Comment by Tim Paul posted on

      That's a really good question - no they don't. We generally discourage use of disabled form elements as they can be quite misleading, and often they've been greyed out to the point where any text is no longer accessible.

      However, I've raised an issue and we'll definitely discuss this soon. Thanks.

      Reply
  5. Comment by Jay spanton posted on

    Hi Tim, did you ask the browser makers if they would allow resizing of native controls in future e.g based on font size of label? Would guess this is a very, very widespread problem (small screens, accessibility etc).

    Keep up the good work and published explanations.

    Cheers Jay

    Reply
    • Replies to Jay spanton>

      Comment by Tim Paul posted on

      Hi Jay, yes that was the first thing we tried. Sadly, all but one of them ignored our requests. Robin Whittleton will be blogging very soon about the fun they had implementing accessible, cross-browser custom form controls 🙂

      Reply
  6. Comment by Jonathan Hartley posted on

    Thanks for sharing. Are forms using the custom controls still usable using keyboard only (i.e. no mouse)?

    Reply
    • Replies to Jonathan Hartley>

      Comment by Tim Paul posted on

      Yes they are. All our forms are keyboard accessible, with visible focus states.

      Reply
  7. Comment by Pete Smith posted on

    I row of the new check boxes does have some affordance that they are boxes to be ticked. Personally I'm not a fan of totally flat as I think we should help users see interative elements more clearly with some design hints. The browser form element furniture does this on many operating systems, But if flat is working, that's all that matters, I guess.

    Have you texted single check boxes in isolation? e.g: 'Confirm you agree'. Or do you try to avoid using single check boxes like this?

    My point is that the single flat check box may have a lot less affordance.

    Reply
    • Replies to Pete Smith>

      Comment by Tim Paul posted on

      Hi Pete. Affordance is something we were concerned about as well, but the research we've done has reassured us that this design works. You make a good point about single checkboxes though - we don't encourage their use but I'll make sure we test them.

      This is a pure reckon, but I wonder if users are slowly becoming more habituated to a less skeumorphic design? As the web becomes mainstream perhaps we can rely less on those visual metaphors.

      Reply
    • Replies to Pete Smith>

      Comment by Luke posted on

      They definitely have a lot less affordance. They also look near identical to two-digit input boxes. I don't think testing for these will have been on a large scale.

      Reply
  8. Comment by Jonas posted on

    I am a bit puzzled. Where exactly lies the problem? Your checkboxes are wrapped with the labels. I does not matter where you click, if you try to hit the small check box and fail, it will be checked regardless because you hit the label. So on the ux side of things it does not matter.

    Or was it a bigger problem that the checkboxes weren't clicked at all?

    Reply
    • Replies to Jonas>

      Comment by Tim Paul posted on

      Hi Jonas. It wasn't that users were failing to hit the smaller controls, it was that it was taking them more time and effort to hit them. Dragging a mouse cursor over a smaller region is just more difficult. By making the controls bigger we made their default behaviour easier.

      Reply
    • Replies to Jonas>

      Comment by Sarah posted on

      I disagree that there wasn't a UX problem. The X in UX is of course 'experience', just because a task can be completed doesn't mean the experience was as good as it could be. As the author states, if things are confusing and take extra time or effort than they could then the UX has room to improve.

      Great job as usual by the GDS

      Reply
  9. Comment by James Cliburn posted on

    Because you've replaced the native components with custom ones, how is the performance with voiceover software on desktop or mobile? Didn't see any mention of them in the article or comments.

    Reply
    • Replies to James Cliburn>

      Comment by Tim Paul posted on

      Hi James. Yes, we tested the new code and also had the Digital Accessibility Centre test it for us. We uncovered issues with labels not being read out: in VoiceOver using Chrome version 53 and on version 13 of Dragon NaturallySpeaking. Both of these were general issues, not caused specifically by our code. Both issues have been fixed in later versions of those browsers.

      Reply
  10. Comment by James posted on

    Affordance wise, I'm a supporter of the "flat" aesthetic in this instance as it's a direct representation of a physical form and maps better to users mental models of a typical form filling experience. It feels like you should use a pen, but you don't have a pen, you have a click, so you click it. Rather than making it look like a thing you could click, which is much more uncertain for many users, this approach makes it look like a form they've seen for many years prior to web use. This facilitates a re-shaping of said mental models when more and more users use online forms in the future. A nicely timed bridging of expectations across generations. 🙂

    Not only this, radio's are circles and check boxes (ticks to many) are square. Regardless of Fitt's Law, mapping and feedback are clear winners here. Nice work!

    Reply
    • Replies to James>

      Comment by Tim Paul posted on

      Thanks James. We actually considered making both controls squares (the square/circle convention isn't universally understood), but if felt like a step too far at this point in time.

      Reply
  11. Comment by avangelist posted on

    This is stupid.
    I mean, well done, but come on. You haven't solved any problem the user had.
    A problem would have been if they weren't able to complete the form because they were clicking on the wrong radio, or check. They weren't.

    This is some bugbear from someone, not a problem.

    Labels have been clickable with the correct code since their inception near enough - that's almost 30years. The fact that so many people fail to write the correct code is the problem.

    Reply
    • Replies to avangelist>

      Comment by Tim Paul posted on

      Hi Andy. You're right that it's poorly coded websites that have caused the issue - people justifiably don't trust that they can click on radio or checkbox labels. And you're right that it's not a deal breaker for most people - it just means that it takes them slightly more time and effort to use a form.

      But for a minority of people with very poor motor skills it will be significantly harder to click a smaller control. Given that making the controls bigger doesn't make the experience worse for anyone else we thought it was worth the effort to help that group.

      Reply
      • Replies to Tim Paul>

        Comment by Luke posted on

        By this argument, you should scale up buttons as well, surely? Given that relative scale (of elements to each other) is a useful signifier, might this be considered in future?

        Reply
        • Replies to Luke>

          Comment by Tim Paul posted on

          Hi Luke,

          I think there's a law of diminishing returns. Beyond a certain point you're no longer adding much benefit and may in fact be making things worse in other ways.

          Reply
  12. Comment by Bayes posted on

    Does leaving inline checkbox unstyled wasn't confusing for users? The big ones are the same on every system but the inline ones are different.

    Reply
    • Replies to Bayes>

      Comment by Tim Paul posted on

      The intention is for the new controls to be used everywhere. We try to avoid lots of inline form controls as they're harder to scan. However there are some cases where inline controls are appropriate (some administration systems for example). It's possible that a future iteration of these styles will include different sizing options to support those cases.

      Reply
  13. Comment by Lewis Cowles posted on

    * It looks nice, works on mobile and PC.
    * I see you've used CSS transforms to make a border into a tick and are making use of positioning, top, left & margins. Did you consider going easier with a picture background?
    * This also uses JS to style... Did you consider using sibling selectors and just CSS?
    * Is the government going to release data from research?

    Reply
    • Replies to Lewis Cowles>

      Comment by Robin Whittleton posted on

      We did initially consider using an SVG, but this approach was easier to iterate the design on and works fine in every browser we’ve tested in.

      It would have been nice to achieve the look we needed without JS, however we didn’t want developers to have to update every use of the existing markup pattern to adopt the new style. If the :has pseudoclass was available in every browser we test in then we could have done it without JS but we’re not there yet.

      Reply
  14. Comment by Sam Toms posted on

    At first my reaction was that you went backwards in terms of usability. It is interesting that you can make it so easy for users to complete a task and still they will click the area which is the most difficult.

    Reply
    • Replies to Sam Toms>

      Comment by Tim Paul posted on

      Yes, I think the lesson here is that people's past experience on other websites has a big effect on their behaviour on your site.

      Reply
  15. Comment by Ed posted on

    Hi, will this change affect inline checkboxes?

    "large hit areas aren't always appropriate"

    I'm curious why the need to have large hit areas is removed when the checkbox directly relates to an input field. Would having 2 different types of checkbox not confuse some users?

    Reply
    • Replies to Ed>

      Comment by Tim Paul posted on

      We tend to discourage lots of inline form controls as they can be harder to scan, especially if you're using a screen magnifier. There are a few exceptions which the new design supports - simple 'Yes/No' radios for example.

      Reply
  16. Comment by jack daniel posted on

    Your previous big grey box look pretty good UX. About your findings, what I would have done rather is to remove the checkbox altogether and only when the user clicks the box, show the check mark.
    Maybe to further indicate that the box should receive an input, in the non-active state make the checkbox look like a small dot or any such plain shaped symbol. So when someone selects the grey box, the plain shaped symbol transforms to a check mark.

    Reply
  17. Comment by James Grumish posted on

    Has your team gone through a similar process with select elements? I'd be very interested in what you arrived at using.

    Reply
    • Replies to James Grumish>

      Comment by Tim Paul posted on

      Our recommendation is to avoid select boxes where possible, because they hide choices and are really hard for some people to use. We've prototyped a few custom select boxes before that address some of these issues, but we'd need to do more research before including one here.

      Reply
      • Replies to Tim Paul>

        Comment by Ed posted on

        If a user know's what the choices will be (i.e pick a day of the week), then nothing is being hidden as the user already knows what to expect when they click it.

        Reply
        • Replies to Ed>

          Comment by Tim Paul posted on

          Yes that's true, but there's still the issue of some users struggling to interact with the control itself (I didn't really believe this happened until I saw it myself). As with most things it's difficult to give 'always do this, never do that' type answers - you have to know your users and exercise judgement.

          Reply
  18. Comment by @popmugart posted on

    Read the tweet. Came to have a look. Fascinating. Choosing to always click on the control is perfectly rational user behaviour because it conforms to people’s behaviours learned in relation to paper. Think vote! You’re taught to make/write/put your tick/cross IN the box. This is what we do generally. And such general applicable knowledge naturally gets transferred to the digital representation as well. So, I guess, make them bigger is always better! Remember ratio of finger size to box size in relation to smartPhone/tablet! Plus an explicit instruction, like: tap/click in the box will help.

    Reply
  19. Comment by Dan posted on

    Your solution to people always clicking on the circles and boxes instead of labels was to.. make it easier for people to click the circles and boxes?

    Why not teach the users instead? People (usually) know things like hyperlinks, so did you try things like showing a hyperlink underline when users hover over both the label and the box/circle, giving the hint that the label is clickable too?

    Reply
    • Replies to Dan>

      Comment by Tim Paul posted on

      We tried changing the hover state with a border and background effect - and were surprised when it didn't have much of an effect on user behaviour. I think hyperlink underlines are worth trying, though it's not going to work for many touch devices. As always, we're never done - if we have an opportunity to test other ideas we will.

      Reply
  20. Comment by mfreeman posted on

    These are simplistically wonderful. Used hand in hand with other form elements, I can't see how anybody can misunderstand that these are interactive. The other form elements set up a UI pattern that seems crystal clear to me. They are a fair chunk bigger than a standard checkbox but size definitely matters nowadays with tappable regions and large resolutions. Very nice.

    Reply
  21. Comment by Sik posted on

    Honestly those custom controls look a lot like their paper counterparts. No wonder that people don't seem to have much trouble with them.

    Reply
  22. Comment by Ryan posted on

    I figure this would be nicer without the js, but I can't get it to work properly. Why does this not work to show the check in the box?
    input:checked + label:after {
    opacity: 1;
    }

    http://codepen.io/anon/pen/NbYXQZ

    Reply
    • Replies to Ryan>

      Comment by Andrew posted on

      @Ryan: I posted an example yesterday containing a css only solution, that I put on jsbin. But the comment was removed for some reason.

      Reply
      • Replies to Andrew>

        Comment by Angus Montgomery posted on

        Hi Andrew, that link had triggered a malware warning on WordPress so I'm afraid we had to remove it.

        Reply
      • Replies to Andrew>

        Comment by Tim Paul posted on

        Hi Andrew, we'll be taking a look at your example though - thanks for posting it.

        Reply
      • Replies to Andrew>

        Comment by Ryan posted on

        Andrew, is it possible you can try to forge the jsbin link in the comment? I'd like to see what it looks like.

        Reply
    • Replies to Ryan>

      Comment by mfreeman posted on

      I think for that to work you would need the label to be after the input. I'm guessing this is why the JS solution has been used although I've not looked at it in detail.

      Reply
      • Replies to mfreeman>

        Comment by Tim Paul posted on

        You're right, we wanted a solution that didn't require service teams to re-code their HTML.

        Reply
      • Replies to mfreeman>

        Comment by Ryan posted on

        mfreeman, you're right. If the label is moved to after the input everything works properly. Thanks!

        Reply
  23. Comment by Ali Langarizadeh posted on

    Interesting ...

    but a question:
    In your assessment, do you understand which kind of your users have problem with "standard controls" (I mean age, sex, nationality, ... for example)? And how many of them (%)?

    Thanks (and excuse me for my bad English language)

    Reply
    • Replies to Ali Langarizadeh>

      Comment by Tim Paul posted on

      Hi Ali. Our research has been lab based and more qualitative than quantitive, so we don't have percentages. But we saw enough evidence to be confident that making the change would be worth it.

      The increased size of the controls will benefit anyone who has impaired motor control - whether that's permanent or temporary.

      Regarding people's tendency to click the control rather than the label - it's not limited to novice internet users (I've watched colleagues do it as well). I think this is because it's not about a lack of awareness, it's a response to the unpredictable nature of form labels on the web.

      Reply
  24. Comment by Jason Rogers posted on

    Overall the size of the text and controls on GOV.UK is way too big. I realise that there are some users who need / wish for bigger text.
    Overall the site is like railway ticket machines - the majority of rail users need to bend down to use the machines, reducing usability and increasing errors (visit a major railway station to see this in action) yet the vast majority of users are not in wheelchairs.
    Why can't we have a simple switch between "standard" size and "increased" size of text etc?
    For context, I am aged over 50 and do need reading glasses - so don't think I am a youngster. Equally, do not think that I do not know about these issues - I have been involved in user interfaces since before the World Wide Web!

    Reply
    • Replies to Jason Rogers>

      Comment by Tim Paul posted on

      Hi Jason, thanks for your reply. We try to make GOV.UK easy for as many people as possible to use, so we err on the side of larger text. GOV.UK is coded so that you can change the size of the text to suit your preferences. For example, in Chrome you can make the text smaller by pressing CMD and the minus key. Unfortunately, lots of people are unaware that you can do this - it's something we're looking at.

      Reply
  25. Comment by Miklos Philips posted on

    "We thought this would work, so we rolled out the design across services on GOV.UK." ha, really? Do you mean to tell me you did NOT do any user testing before your rolled it out? 🙂

    Reply
    • Replies to Miklos Philips>

      Comment by Tim Paul posted on

      We did some research but it was inconclusive so we decided to roll it out. Our reasoning was that the only way we'd be sure either way was to use the checkboxes in multiple services and see how they performed.

      Reply
  26. Comment by Andrew Welch posted on

    • Replies to Andrew Welch>

      Comment by Tim Paul posted on

      Thanks Andrew - I've raised a bug and we'll fix it as soon as possible.

      Reply
  27. Comment by Jo Goodwin posted on

    Hello, Have you tested checkboxes on the right versus checkboxes on the left? For mobile, tablet and desktop? We'd be interested in the results if so.

    Reply
    • Replies to Jo Goodwin>

      Comment by Tim Paul posted on

      Hi Jo, thanks for your comment. No, we didn't test with right-aligned checkboxes - we decided to stick with the left aligned convention. Some mobile devices have a convention of right-aligned toggles, which are functionally equivalent but tend to carry a slightly different meaning (on/off versus yes/no). There's an interesting debate about checkboxes versus toggles here: https://ux.stackexchange.com/questions/63884/checkbox-vs-toggle

      Reply
  28. Comment by shojib islam posted on

    good post dear

    Reply

Leave a comment

We only ask for your email address so we know you're a real person