After launching an improved style for the radio buttons and checkboxes, we initially experienced some browser issues that prevented the new styles from displaying correctly. We’ve now managed to overcome these issues but only by customising the form controls used by browsers.
Getting browser vendors to fix their bugs
In October we filed issues with various vendors about radio buttons and checkbox bugs in their browsers. Unfortunately, with the exception of Opera, these bugs have not yet been fixed.
Some of the bugs we filed were just about visual polish. But, during user research sessions, we found a bug in iOS that was confusing for users. This bug means that when you resize a radio button, instead of rendering a bigger circle the browser adds straight lines in between the normal sized corners (as you can see from the below).
Users find it hard to distinguish these big radio buttons from big checkboxes (and they need to be able to do this on forms so they can understand how many answers to give). Seeing as iOS users make up around a quarter of the visitors to GOV.UK we were unecessarily causing problems for a lot of people.
Other bugs present included small and non-resizeable inputs in Firefox on Windows, and in Chrome and Safari on macOS. Chrome and Safari on macOS also suffered from a bug where the inputs jumped up and down when they were selected.
We weren’t meeting our user’s needs with all of these problems, and needed to try a new approach.
A new style for radios and checkboxes
If we can’t rely on browsers to produce working radios and checkboxes, then what can we do? We can build our own custom ones. Usually, we’d rather use native browser form controls, but in this case the native controls have some serious bugs.
We started with a pre-existing design that we’d developed and started testing a couple of years ago. This looked similar to the Internet Explorer controls, and was relatively easy to build out over the existing HTML.
You can read Tim Paul’s blog post on updating the design of the radio buttons and checkboxes for more detail.
Technically, the implementation is reasonably simple. We hide the native control, but leave space for the custom control to appear. We then use CSS generated content hooks: the first for the container and the second for the checked mark. We generate these with borders and transformations instead of using images. This keeps things sharp on high resolution displays and reduces the page weight.
The colour of the new radio buttons and checkboxes will match the text colour, and their background is transparent. This works better for people who change their browser’s default colours, or those who use high contrast themes in Windows.
While we have a list of recommended browsers and devices that services should test in, it’s important that libraries of interface code go further. We’ve tested back to early versions of all of our common browsers, and many rarer ones too. In Internet Explorer 6-8 the user will see their browser’s native controls as those browsers don’t support the technology we’re using to build the custom controls. More modern browsers can support the custom controls .
Making custom controls accessible
One of the reasons why we generally avoid custom form controls is that browsers build in a lot of accessibility features to their native controls that are important to replicate.
When making our updates, we solved a lot of the potential problems by reusing a visually hidden native control. The custom controls we have built are invisible to screen-readers, but they have access to the underlying native technology.
We did run into a problem with a class of assistive technology that is not often considered when building websites: speech recognition software.
The market leader for this is Dragon NaturallySpeaking. Version 12 worked fine with the new radio buttons, but version 13 failed to recognise the inputs – the user couldn’t click on them. We narrowed this down to the code we were using to hide the native controls. As soon as we reduced the control in size to near-invisibility, or positioned the control outside off-screen NaturallySpeaking was unable to interact with it. We solved this issue by making the control completely transparent, which meant NaturallySpeaking 13 was able to recognise it.
Rolling it out
Making new radio buttons and checkboxes is no use if no-one can use them.
Designers prototyping new government services can use version 5.0.0 or up of the GOV.UK Prototype Kit to use the new inputs. Developers on government services can use them by using version 2.2.0 or up of GOV.UK Elements, our library of service patterns. Existing inputs will automatically get the new look and feel.
With a site as big as GOV.UK there will be a lag as individual services upgrade to the newer style. Since making the radio buttons and checkboxes available, the Department for Work and Pensions have upgraded the Job Centre service ‘Prove you can apply for benefits in the UK’ to use them and have had good feedback. There are new services being developed by the Department for International Trade and the Land Registry, and the NHS beta team are trialling them. We have also updated GOV.UK Verify to use the latest version of the inputs.
We would still like vendors to fix the bugs in their browsers. If, in the future, we can resize radio buttons and checkboxes without any problems then we may change back to using native controls. For the present, our custom controls provide the best experience for people using our services.
If you manage a government service and you’re unsure how to implement these custom controls then leave a comment and we’ll get in touch.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.