This is the second entry in the series Modern Web Form Best Practices.
“Checkbox” form controls have long been a part of software. They enable users to provide a simple binary response—yes or no. On the Web, we often see them in two scenarios: confirmations and multiple choice.
Standalone checkboxes are often employed to enable users to affirm a statement, as in this example from the American Express login form where a customer can indicate they’d like the site to remember them.
Here’s a simplification of the markup they’re using:
<div><script src="https://gist.github.com/d281f889a11634b45280.js?file=american-express-login-simplified.html"></script> <noscript><pre><code><input type="checkbox" id="lilo_checkBox" name="REMEMBERME"> <label for="lilo_checkBox">Remember Me</label></code></pre></noscript></div>
This works really well, though I generally prefer to combine explicit and implicit labeling to simplify my CSS selectors and broaden their applicability. Here’s how I would rewrite this control:
<div><script src="https://gist.github.com/d281f889a11634b45280.js?file=american-express-login-reimagined.html"></script> <noscript><pre><code><label for="lilo_checkBox"> <input type="checkbox" id="lilo_checkBox" name="REMEMBERME"> Remember Me </label></code></pre></noscript></div>
Regardless of the markup pattern itself, it’s important to note the explicit association of the form control and the
label element (using the
for attribute). You’ll also notice the input has a straightforward
name value which will be submitted to the back end if the user ticks the box.
It’s worth noting that some back-end systems may require a value be submitted for the given variable name (in this case, “REMEMBERME”) regardless of whether the user has ticked the checkbox. If that’s a requirement, you can alter the pattern to use a hidden
input as well:
<div><script src="https://gist.github.com/d281f889a11634b45280.js?file=american-express-login-with-hidden.html"></script> <noscript><pre><code><input type="hidden" name="REMEMBERME" value="no"> <input type="checkbox" id="lilo_checkBox" name="REMEMBERME" value="yes"> <label for="lilo_checkBox">Remember Me</label></code></pre></noscript></div>
The source order matters because with matching
name values, the final submittable
value will always be the one the back-end receives. With this setup, the
value of “no” (from the hidden
input) will be submitted by default. If the checkbox is ticked, its
value is submitted instead, setting REMEMBERME to “yes”.
Multiple Choice Checkboxes
The other way we often see checkboxes used is to enable users to choose zero or more items from a collection of options. Consider this example from the Chattanooga Open Device Lab’s reservation form. It allows users to choose the devices they’d like to include in their test matrix:
The markup they employ is pretty well-organized and straightforward: it’s a list of checkbox options.
<div><script src="https://gist.github.com/d281f889a11634b45280.js?file=chaodl-checkbox-list.html"></script> <noscript><pre><code><ul> <li> <label for="nintendo-ds-lite"> <input type="checkbox" name="reservation_requested_device" id="nintendo-ds-lite" value="Nintendo DS Lite (Upper Cabinet #13)" data-checkbox-required="" > Nintendo DS Lite </label> </li> <li> <label for="nintendo-wii"> <input type="checkbox" name="reservation_requested_device" id="nintendo-wii" value="Nintendo Wii (TV Area)" data-checkbox-required="" > Nintendo Wii </label> </li> <!-- list continues --> </ul></code></pre></noscript></div>
As this is an instance where a user could choose more than one option, the back end needs to be able to capture that information in what’s called an “array”. An array, if you’re unfamiliar, is a collection of values. You’ll notice that the
name given to each of these checkbox
input elements is the same: “reservation_requested_device”. The square brackets (“”) at the end of the
name are the magic bit that allows the values of each chosen “reservation_requested_device” checkbox to be submitted as the value of “reservation_requested_device”.
Checkbox controls only use a subset of the typical
input attributes. In particular, you’ll need to include
name- This is the variable name you want to hold the user’s response. As mentioned in the previous section, appending “” to the variable name will allow the variable to hold all of the user’s choices as opposed to only the final one.
value- This is the value that should be captured if the user ticks the checkbox.
id- The unique identifier you’re using for the control in order to explicitly associate it with a
There are a few optional attributes you might consider including as well.
checked- Use this null attribute if you want the default state of the checkbox to be ticked. This attribute should be used with caution. Don’t use this attribute to automatically check confirmation boxes for things like mailing list opt-ins. Do use this attribute when you are displaying sensible default settings or displaying confirmations the user has already made (e.g. in the user’s profile or when re-displaying the form when it has a submission error).
Checkbox vs. Other Controls
Checkboxes excel at allowing users to indicate preference from a pre-defined set of options. But there are other form control types that allow for similar control over user responses. That can make it difficult to decide which element to use.
Dropdown List (
select element is another tried and true option for allowing users to indicate preference. A simple two-choice
select elements require more clicks of your users. They also obscure the complete list of choices from view because only one options is displayed at a time. Their appearance makes them more compact, but can make it difficult to get a complete picture of what choices are available when you can’t see them all.
You can enable multiple choice in a
select element by adding the
multiple attribute to it, but depending on the number of
option elements, it could also be a little unwieldy. Depending on the size of the
select and the number of options, you could also create an inner scroll that could be awkward on certain touch-based devices.
select element has its place, but should be used sparingly. I’ll go in-depth with
select elements in a future post.
Choose One (
For simple confirmation questions, it’s completely valid to use a radio form control in lieu of a single checkbox. In fact, in some cases, it may offer a more explicit choice for your users. Consider this example from Subway’s online ordering tool.
A checkbox labelled “Fresh Toasted”, isn’t terribly clear. A better approach would be to ask something like “Would you like your sandwich toasted?” with radio controls for “yes” and “no”. Alternately, if they absolutely wanted to keep it as a checkbox, they could use a better label: “Please toast my sandwich”.
Radio controls have their place, but are not often a one-to-one replacement for checkboxes. I will discuss radio controls in greater depth in another post.
Check ’Em Out
Checkboxes are an invaluable tool in the form building tool chest. Understanding their purpose and capabilities is key to using them properly and ensuring your forms are usable to the broadest number of users.
Well, this is timely! Just today I was having a really good natter with Charlotte about using checkboxes, specifically sending multiple values to the server:
You’ll notice that the
namegiven to each of these checkbox
inputelements is the same: “reservationrequesteddevice”. The square brackets (“”) at the end of the
nameare the magic bit that allows the values of each chosen “reservationrequesteddevice” checkbox to be submitted as the value of “reservationrequesteddevice”.
See, I wasn’t sure whether that was just a PHP thing (the only server-side input-handling I’ve had much experience of) or whether it was a more general way of sending multiple values.