Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

I frequently receive mock-ups of HTML forms with the following prototype:

Some long winded yes or no question?   (o) Yes   ( ) No

The (o) and ( ) in this prototype represent radio buttons. My personal view is that if the question has only a true or false value then it should be a check box. That said, I have seen this sort of "layout" from almost every designer I've ever worked with.

If I were not to question their decision, or question the client's decision, I'd probably mark it up like this:

<p class="pseudo_label">Some long winded yes or no question?</p>
<input type="radio" name="the_question" id="the_question_yes" value="1">
<label for="the_question_yes" class="after_radio">Yes</label>
<input type="radio" name="the_question" id="the_question_no" value="0">
<label for="the_question_no" class="after_radio">No</label>

I really don't want to do that. I want to push back and convince them that this should really be a check box and not two radio buttons. But my question is, if I can't convince them – you're welcome to help me try – how should I code that original design requirement such that it is semantic and at least understandable for screen reader users?

If I were able to convince my tormentors to change their minds, I would likely code it in the following fashion:

<label for="the_question">Some long winded yes or no question?</label>
<input type="checkbox" name="the_question" id="the_question" value="1">

What do you think about this issue? Should I push back? Possibly more importantly is either way semantically correct?

UPDATE: I have posted a related question on the UI SE per your suggestions. You can find it here: http://ui.stackexchange.com/q/3335/3493

share|improve this question
3  
You might get better input on this over on the User Interface stackexchange (ui.stackexchange.com) –  Bevan Feb 1 '11 at 23:23
1  
I don't see what is so wrong with the designer's mockup. There are perfectly valid reasons for not using checkboxes for yes/no questions--e.g. making sure the user answers each question, or keeping the UI consistent when you also have non-yes/no questions, or to distinguish a questionnaire from a checklist. –  Lèse majesté Feb 2 '11 at 6:25
    
@Bevan thanks for your suggestion. I have done just that. I have added the link to the OP. –  sholsinger Feb 3 '11 at 3:38
add comment

3 Answers

up vote 3 down vote accepted

While your checkbox idea is much more efficient, I think you would have to avoid stating it as a question for it to make sense. For instance:

<label for="the_question">I would answer yes to this long winded question.</label>
<input type="checkbox" name="the_question" id="the_question" value="1">

However, if your designers are dead set on keeping the radio button model, I think using the fieldset tag makes much more semantic sense.

<fieldset>
  <legend>Some long winded yes or no question?</legend>
  <input type="radio" name="the_question" id="the_question_yes" value="1">
  <label for="the_question_yes" class="after_radio">Yes</label>
  <input type="radio" name="the_question" id="the_question_no" value="0">
  <label for="the_question_no" class="after_radio">No</label>
</fieldset>

I've heard rumors that some screen readers have the nasty habit of skipping paragraphs while they're reading forms, which would cause a problem if you've posed the question in a paragraph. Not entirely sure if that's accurate or not, though.

share|improve this answer
    
+1 on the fieldset idea. That's far more "semantic" than anything I had thought of. I can see a use for merging the idea of turning the labels for the radio buttons into longer statements of the answer. 'Yes, positive answer to this question.' or 'No, negative answer to this question.' Shortening the question to be more direct, placing it in a legend element and wrapping it all within a fieldset. Thanks for your contribution! –  sholsinger Feb 3 '11 at 19:47
add comment

I disagree with both of the approaches.

Mostly, if the "long winded question" really does have two answers then "Yes" and "No" are poor choices to offer. The options should be short phrases that state the decision being made.

An example. Instead of this:

Do you want to book conference accomodation now as a part of your ticket?
( ) Yes
( ) No

do this

Do you want to book conference accomodation now as a part of your ticket?
( ) I do want to book accomodation
( ) I will arrange my own accomodation

share|improve this answer
1  
I think the designer's original choice has merit. It separates the unanswered questions from the answered questions, and the answer choices are simple and quicker to read/identify. Though your approach makes the answer options more clear. This might be a better option if the question is particularly long (e.g. there is background info provided along with the question) or to clarify what each option is. Just be sure to stick with a consistent order for affirmative/negative options. Also, try to make the options as short/concise as possible--e.g. "Book my accommodation now." –  Lèse majesté Feb 2 '11 at 6:00
add comment

The designers have a specific set of skills that many programmers do not have. Likewise, most programmers have a specific set of skills that many designers do not. Sometimes the skills cross over, but the true experts specialize.

Some programmers have a background in Computer Science. They learn things that most laypersons will never even contemplate. These skills help these programmers solve very complicated problems.

Some designers have formal education in Graphics Design and Usability. They study human behavior. They study the differences between different user interfaces and they apply their specialized knowledge in the real world.

Although you may disagree, do what the designers ask. I work with designers who build $15,000 websites for attorneys, and every decision they make is intended to make the application as clear and intuitive as possible.

Trust your designers to do their job and produce money-making designs. In turn, they'll trust you to produce a high quality application that brings their powerful vision to life.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.