Checkboxes and radio buttons often get ignored by designers because they’re not used as often on forms as text fields. They may look small, but they can pack a strong punch when it comes to form questions. That’s why it’s important to make your checkboxes and radio buttons easy to use with hover effects.
The problem with check boxes and radio buttons is that they have small click targets. To activate them, the user has to click a tiny square or circle. Sometimes there’s an option to click the label. However, that option is not always available on all forms. But when it is available, that option is never clear and intuitive to the user. Making the label clickable does make their click targets bigger, but there is still a lack of clarity in its affordance.
Displaying a hover effect when users move their mouse over a checkbox or radio button can create a stronger and more intuitive affordance for users. The hover effect visually tells users that the label is a clickable target. When they see the hover effect, it prepares them to click the label.
Adding a hover effect to your checkboxes and radio buttons solves the problem of small click targets. By letting users know that they can click the label, you save users time and energy when they’re using your application. The big things may get most of our attention, but in this case, it’s the little things that count.
Book
Affiliate
There was also that “hand” cursor to indicate “clickability”.
Stephan
Most check boxes don’t use hand cursors. They’re usually arrow pointers instead.
This could get confusing, as ‘pointer’ in CSS is usually rendered as a hand cursor.
Checkbox labels usually are the default cursor, and they would benefit from having the hand/pointer cursor
PS, uxmovement, your twitter button is broken, at least on newtwitter. I don’t get the link, just the text, in my tweet box.
If you’re going to do that why not just make the checkbox bigger?
I used to think the same thing. Unfortunately mobile phones don’t support the rollover event.
Then it occurred to me that thats why Apple went with the toggle UI. This was a genius move. Although to make the toggle work, you need a very short description. (on/off, yes/no, etc)
Worse, for those of us not developing only for the iPhone, there are drawbacks. There are javascript and jQuery solutions for this. But then you need to require javascript and download some images and it adds complexity, makes things more fragile, is harder to maintain, adds concerns over compatibility, and I don’t even know if there are performance issues. So there is some trade off.
Most browsers already do this – they obey the OS’ conventions, and on Windows and many Linux distros, highlight on label hover is the default. OSX doesn’t support it.
Glen I dont think that is the defult, atleast it wasnt for me with Vista, IE, and FF.
For me, by default. when I move my cursor over the label the cursor changes to the text and it does not change the color of the Checkbox.
Too bad they didnt put a Checkbox in the post so that we could see the default behavior.
For years I’ve been adding “cursor:pointer” to all my labels for radio buttons and checkboxes. It’s a tiny detail that makes a big difference to the usability of a form.
Occasionally (very often in my case) you will have a grid of checkboxes that do not have a field label. It makes much more sense to find a way to make the check boxes themselves larger.
interesting, but not as good a solution as could be imagined. here’s a better mechanism (caveat: i’ve put about 2 seconds of thought into it).
this proposal doesn’t indicate that what’s going to change is the radio button – it only indicates that *something* will change. (and what does ‘prepare’ mean?). what would work much better is a ‘halfway’ state – where the checkbox turns, on hover, into a checkbox with a translucent/faded check in it, which then becomes solid/opaque on actually clicking the label. not being a css geek, i don’t know if this is actually possible (but if it isn’t, it should be standard behaviour on all pointer-based UIs).
apple’s toggle button solution is still superior. also, once someone encounters a hand cursor over a checkbox label, they’re probably going to look for that in future before heading to the checkbox.
The added text in any color does not help relay to end user the text is clickable.
The addition of the text to the left in itself is an attention getter as it not commonly found there. (cause for end-user to pause)
Addition of the text needlessly uses up precious real estate.
Use of Red Yellow Green should always be used judiciously as each color has strong associations to levels of importance over use of them only goes towards lessening their importance, and power to call attention to issues at hand.
Adding colors goes to add one more layer of information the end-user must process to complete the task.
Adding T
Curser changes to hand while over area designated.
Increase the area around check box that will enable disable the check box.
Once checked the label/string/ dynamically changes to being Bold.
The simplest solution that worked – based on client feedback – was to add the CSS rule for labels:
label:hover {
text-shadow: 0px 0px 2px black;
}
But this does not work for mobile devices.
Seems those concerned with “hover doesn’t work on mobile” are missing the boat on UI. Mobile and desktop UI are two different animals.
If we want to talk responsive design, that is yet another element.
But the POINT of the article, is that it would be helpful if the user had some visual cue tying the label, as a clickable area, to the checkbox. Preferably with some tactile feedback.
Bottom line, this is not a white paper. Not even an article. It is just a point being made.
Point taken.