One of my favourite web widgets are radio buttons. I don't know why, but I always liked working with them. Soon I am going to be working with them less because their usability issues. I went looking for posts of this, but I only really found one blog post about some of the issues.
One of the reasons I was told for not using them is that they don't scale when you enlarge the text. What's the alternative? Use drop-down menus. They function the same way, but they work so much nicer. It should be trivial to switch from one widget to another.
Sadly there isn't really an alternative for checkboxes, so they are still in. I hate checkboxes... They have burned me too many times with forms in session. I know, I know... use request scope...
Here are the 2 widgets. Play with the text size in your browser and see how it handles it when the text gets really big. I swear that the radio button actually shrinks...
I would like to know where in the w3c spec it says the id field has to be the same as the name field. I'm not sure where this can be found. Looking here
ReplyDeletehttp://www.w3.org/TR/html4/struct/global.html#adef-id
All I could find was that the ID field is "a" name, not that it has to be the same as "the" name. And it is stated that the ID must be unique, but obviously the name does not have to be unique.
Also, the problem with the radio button not scaling is more a problem with the user agent (browser) than the W3C spec itself. I tried this out in Opera, and it worked fine. The radio button scales without any problems. Of course I Opera has a zoom option, an no option just to increase the text size as firefox does. Sadly, I couldn't find any other browser that exhibits this behaviour.
I also find that radio buttons work a lot better than drop down lists when there is more than just a short text label beside the option, and when you want the user to be able to see all the options at once. Think of an online app to buy a computer system. Lising all the hard drives in a drop down list with the specs, make, model, of each hard drive wouldn't work as well as having a radio button, with the information shown beside the radio button. You could lay out the information much better that way.
Also, I have no idea what you mean with your rant about checkboxes. I've never had any problems with those either.
When a checkbox is unchecked the browser doesn't send any value for that widget.
ReplyDeleteIf you have a (struts) form in session, then you have to explicitly clear the checkboxes and struts will fill in the values sent for that request. I've just been frustrated when I've worked with them before compared to other widgets.
I don't understand why with html they don't make the buttons change size when the text size changes...
Zoom is different than text change size... it's better for the fact that the layout doesn't get all mangled.
Like I said, it's a problem with the browser. There's no reason why the browser can't change the size of the radio button with the size of the text. Radio buttons are different sizes in different browsers, and on depending on the browser, the radio button may even look different than it does no another browser. HTML or the w3c does not define how big a radio button should be.
ReplyDeleteThat struts problem sounds like a problem with struts, and has nothing to do with the radio buttons itself.
I could just as equally denounce select boxes because floating divs don't display on top of them in IE <=6. That's not the fault of the select box, but rather the fault of browsers not being implemented correctly.
Oh, and I just tried the resize the text thing in IE6, and the select box does not scale with when you change the text size. I set it to smallest, and the select box was the exact same size when I set the font size to smallest. Since IE 6 is probably the most widely used browser in the world, I don't see how your arguement holds any water.
ReplyDeleteSorry, should have previewed
ReplyDeleteThat should have been
I set it to smallest, and the select box was the exact same size when I set the font size to largest.
1) with the struts example, I was talking out checkboxes, not radio buttons. And my complaint is more with the html spec than with struts in that case (not sending info for unchecked boxes).
ReplyDelete2) I agree that it would be wonderful if the radio button itself changed size. I have no idea why it doesn't.
3) I could have sworn that in IE that select box changed size. Humm... I'll have to check what happens in IE 7.
4) I'm just going on what I have been told to do. "There are accessibility issues with radio buttons. The select form control must be used instead."
For more reading please see:
http://www.tbs-sct.gc.ca/clf2-nsi2/tb-bo/td-dt/mfa-rcfa-eng.asp#cn_3.2.2_crb
http://www.tbs-sct.gc.ca/clf-nsi/1/radio_e.asp
If you read the second link (the first link just points to the second), you'll see that the three points they've listed hold no value.
ReplyDeleteThe first is scale with text. Select boxes don't scale with text in IE6, which is the dominant browser, doesn't even scale the select boxes. In fact, I tried this with some other browsers, and Safari does scale, although not at scale at the same rate as the text. If the text gets twice as big, the checkbox only gets a small percentage bigger, maybe 10% bigger.
The second and third deal with screen readers. While I realize that it's important for everyone to have equal access, changing the way the forms work for everybody to accomodate a few users shouldn't be the answer. If you read it, it basically says,
Screen readers suck, and don't know how to handle radio buttons correctly, so to work around that, we're going to make everyone use select boxes instead.
It seems to me that if any problems exist using radio buttons, that the exact same problems exist for checkboxes. Since the only difference is how many options you are allowed to select, I don't see how screen readers could handle these any differently. If using legend, fieldset, and label works fine for checkboxes, why do radio buttons have problems?
While I think I would probably just stick to the rules myself, if I had to work within these rules, I would definitely send an email to the treasury board, outlining the problems with their reasons for not using radio buttons. Being a citizen of this country, I may still send an email pointing out the problems.
It seems to me that somebody with an agenda, maybe someone who didn't like the way radio buttons worked on their particular platform, decided to make up a bunch of reasons why radio buttons are bad, just so they wouldn't have to use them. Especially with the scaling issue, since ie6 doesn't select boxes.
hahaha... ya, I am sure that it's because the anti-radio button lobby has infiltrated the government! ;-P
ReplyDeleteFrom my perspective there is basically no difference between radio button vs. select box usage.
Let's put that sentence in the context of someone that has a different physical disability like needing to use a wheel chair:
"[Wheelchairs] suck, and don't know how to handle [stairs] correctly, so to work around that, we're going to make everyone use [ramps] instead."
(Updated analogy to make more sense)
Does it make any *real* difference to you if you use radio buttons (stairs) or a select box (ramp)? The difference means a whole lot to other people, so why not try to allow them to use it too? I'm assuming that you put html labels on form elements and alt tags on images? Aren't those mostly for screen readers?
They are NOT saying "using legend, fieldset, and label works fine for checkboxes". Since there isn't another widget to use instead of checkboxes, they cannot provide an alternative. If you want an alternative to a checkbox, just make a select box with 2 options in it.
I didn't mean to start a flame war or set you off to march on parliament hill, but to blog about a way to make things easier for people that may use the web differently than you and me.
If you are feeling ambitious, load up Opera and zoom in so that the text is huge (like 20% of the height of your screen). Use your browser like that for a day. If you're cool with that, get a screen reader and turn off your monitor. If you feel you can do that every day and still don't think that accessibility is important, blog about it. I'd be happy to read about your experience.
I didn't say that accessibility wasn't important, what I did say was:
ReplyDeleteWhile I realize that it's important for everyone to have equal access, changing the way the forms work for everybody to accomodate a few users shouldn't be the answer.
So, to take your wheelchair analogy, it would be more like this.
Wheelchairs suck as using stairs, so instead we're going to make everyone take the elevator, even when they're perfectly capable of using the stairs, even to go to the second floor, just because the people in wheelchairs have to use the elevator. We don't care if it takes the person twice as long to take the elevator, because they have to wait forever, we still want them taking the elevator.
This is my point. Don't hobble the masses to make up for the disabilities of the few. Is every government web site not going to put Yes/No questions in the form of a select box, like the one on your blog to save my information? Since they mention rewording the question in order to accomodate the short comings of radio buttons, why not do the same with checkboxes.
Instead of
Which of the following sports do you like
(checkbox) Hockey
(checkbox) Baseball
(checkbox) Soccer
we would have
Do You like Hockey
(select)
Yes
No
(end select)
Do You like Baseball
(select)
Yes
No
(end select)
Do You like Soccer
(select)
Yes
No
(end select)
See, there's a perfectly accessible option for checkboxes. Just reword 1 question with N choices into N questions with 2 choices. Problem solved.
If radio buttons aren't accessible than neither are checkboxes, and since I just demonstrated a perfectly good solution for getting rid of checkboxes, I think they should either do away with both of them, or let web designers use both of them.
I was going to read this, but the comment thread is too long. :)
ReplyDeletehahaha...
ReplyDelete