Semantic Form Markup for Yes or No Questions

Question

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: https://ux.stackexchange.com/q/3335/3493

Answer 1

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.

Answer 2

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

Answer 3

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.