I've got some checkboxes with text values of varying lengths (from say 5 characters up to about 60) - which is the preferred layout? Value to the left and checkbox to the right, or vice versa?
While Microsoft and Apple aren't explicit on this issue, Java Swing Look and Feel Guidelines explicitly state that the label/value should be to the right of the control for languages read left to right. The same applies to radio buttons.
The ancient OSF Motif Style also explicitly says that the label is to the right of check boxes and radio buttons (pg9-133). And, while we're doing archaeology, the IBM Common User Access standards states that the label is right of a check box, but they are silent on radio buttons.
Whatever the explicit standards, it’s pretty clear designers are expected to put the label to the right of the control. The rationale is probably what you’re intuiting. When you have a column of check boxes with labels of various lengths, this arrangement allows both the check boxes and the beginning of the labels to be aligned consistently without any big gaps between the labels and the controls, neatly side-stepping the label alignment issues that text boxes and dropdown lists have. In the dead tree world, labels are often to the right of check boxes and radio button equivalents (e.g., bubbles on optically scanned forms), so this doesn’t throw users.
For picking one or more choices, label to the right. This allows for easy visual scanning and let's the user's mouse/finger flow in a straight line:
[ ] option 1 [ ] this is option 2 [ ] #3
If the label were to the left, it'd be a bit of a mess:
option 1 [ ] this is option 2 [ ] #3 [ ]
Furthermore, you will often have a 'group' label and while that can certainly be placed on top, it's often on the left:
Pick one or more options: [ ] option 1 [ ] this is option 2 [ ] #3
Note that regardless of the positioning, the labels should be clickable as well (use proper FOR attributes). The problem is that not everyone knows this and aims for the checkbox itself, so aligning them helps.
When there is only ONE checkbox, however--typically used for an explicit opt-in or opt-out processes, I think it's OK to put it afterwards to make it a slight bit of a task (as you really do want people to fully read the label):
To opt in to our incessant spam emails we ask that you click this checkbox: [ ]
If we ignore the possibility of right to left reading order (used in some languages), I believe that the label should always be on the right-hand side of the checkbox.
In Windows, it is in fact impossible to put a label to the left of a checkbox, from a technical point of view. In any Windows software development environment a checkbox's label will be on the right hand side of the checkbox automatically. There is no way to change this. What some programmers will do tough is create a checkbox without a label at all, and then put a static label to the left of it as separate control. Besides being ugly it has a mayor drawback: a user can't click the label to edit the checkbox state.
So it should always be on the right hand side of the checkbox. However... I know that some people (and I don't agree with them) feel that there is an exception: when the checkbox is part of a list of other controls. See this example:
So there are people that feel this is right because the alignment looks nicer. I don't. I think the position of the checkbox is right, but the position of the label is not correct. Do you guys see this as an exception?
The basic assumption is that you want to use the most readable option.
One important aspect is scannability, how easy it is to get an overview without consciously considering each item in full. For this purpose it is relevant that checkboxes have a constant width. so if you align one side of the checkboxes vertically, the other side will also be aligned vertically. Text is variable width, so this can generally not be achieved without stretching the text (which can make it very hard to read). It is generally recommended to put the important words at the beginning of sentences, so for LTR text we should prioritize left alignment over right alignment.
Another issue is proximity, how close the relevant information is together. If we put the checkboxes to the right of the label and align them vertically, they will be further away from the labels than if we put them to the left. So the answer seems to be to put them on the left side.
On the other hand, you need to consider consistency within the form. Most form controls are not constant width, and putting them to the left of their labels can often make for an awkward flow (for example, putting the birthday input field to the left of the label), where the user has to go back and forth to scan the form. A compromise would be to use left-aligned controls only if they are all constant and equal width.
Another thing to consider is that a set of radio buttons is equivalent to the default HTML
<select> list, while checkboxes are equivalent to
My instant answer is the that checkbox should be on the left of the label, but before answering I wanted to validate the recommendations.
Sadly Microsoft's, Sun's and IBM's UI guidelines aren't explicit in this regard (they tend to talk about when to use checkboxes over radio button etc.) but all their examples use the control-then-label convention.
So I'd opt for that.
Desktop GUI Toolkits like SWT encapsulate checkboxes as a Button-widget variant, where the text-property of the button becomes the label. It'll get rendered, at least on the systems I'm aware of, on the right of the checkbox. So unlike html, you don't even have to make a choice.
It depends on the use of the check box.
Selection checkboxes (e.g. in a list of items) should be 'before' the text (so, to the left in a left-to-right language like English). This lets you left-align the items and have the checkboxes still be aligned without needless whitespace. It also puts the selection mechanism near the beginning of the label--people don't tend to read the entire label, but instead scan it, and that begins at the mid-left.
In a checklist, the check boxes should come before the text, no question. Users are looking to be taking action on the checkboxes, and are scanning as above.
Options checkboxes, in the context of other options, might be after the label. However, in general I try to stay away from option checkboxes, because they're rather uncommunicative. Newer controls like the iPhone's slider-box are more communicative, or you could use bistate buttons, drop-downs, or other methods for giving the user more insight than a simple "checked/not checked".
From programmer's point of view, box should come before the text, because it's easier to align. From user's point of view, text should come first, because we 1) read what this check box is about 2) decide whether to click on it or not, in this order. So the layout should reflect the user's course of actions.
Id vote for "label comes after" in LTR languages, simple, people will scan down the choices and make checks by clicking on the beginning of the label (it should be supported), or if they are less computer-savvy, look for the checkbox to click, if there are like 5 checkboxes of different label lengths, imagine the trip their hands and eyes and brains have to make from the label to the equivalent checkbox... painful! so the checkbox must be the closest possible to the label to minimize this trip
So for a Windows or Apple software it seems to be clear to put checkbox at left. If it is at right, to respect Gelstat principes the labels have to be align at right to have check boxes aligned verticaly. ..
But for mobile device software checkbox at the right of labels seems better for accessibility. ..
Have à look on SMS manager of smartphone when you want to delete some messages....
I'd also vote for following the "control-then-label" model that someone referenced, but with the caveat that context should take precedence over convention.
For example: There's an online government assistance form that asks users to gather several documents before starting. The system only allows users to proceed to Step 1 of the form if they've checked-off each of the items on the list. In this instance the checkboxes form a checklist, the overwhelming majority of which put boxes on the left.
On the other hand, let's say we have some type of retail/sales application with an employee management section, and you for whatever reason you can select multiple users via checkbox, like so:
Name Title Hire Date Select -------- --------------- --------- ------ John Doe Sales Associate 9/12/03 [x] Jane Doe Regional Manager 12/3/01 [x]
In this case, I think the checkboxes should sit on the right because the connotation is different (you're selecting items for further action, not for elimination from the list). Both iOS (nothing specific in the HIG, weirdly) and Android (http://developer.android.com/guide/topics/ui/controls/checkbox.html) float the checkboxes on the right. To me, this makes the most sense for this type of application because it gives some visual distinction to the checkboxes; floating them left in this instance would, in my opinion, be a little jarring alignment-wise.
There is no one size fits all, but one thing to look at is consistency. You will notice that some pretend that having the checkbox on the left and the label to the right makes for better alignment... and yet would probably never advocate for an edit box control to be seen on the left of it's descriptive label. If alignment was so important they would do it for that too.
Some others mention reading from left to right as being relevant to having the check box to the left of the label... as if reading the text first and the having the checkbox (answer to that text) follow directly is less intuitive than having a checkbox... skipping it to read the label and then scanning back to the left to put your input (essentially the reply to the label). It's hard to see how having to provide the answer prior to the question is fundamentally more intuitive.
So at least for form type interfaces with many inputs, it is clear that the checkboxes should be on the right like all other input controls.