Friday December 14, 2007

Forms: Definition Lists or Tables?

by Alex Bischoff in Technology

13 comments

Last week, a conversation arose as to the best way to mark-up a form consisting of horizontal, label and text field combinations. One of our IAs, coworker Nathan Smith proposed that tables can be used to show semantic relationship, not unlike a definition list. I have thought about it for a bit and would agree that tables are sometimes a workable means for organizing form elements. At the same time, I am not sure that definition lists are inappropriate, either.

---

Example Form — Visual Layout:

---

Definition Lists

Our debate started after the recent posting of an article on 24 Ways by Mark Norm Francis, entitled: My Other Christmas Present Is a Definition List. He makes a good point that a “definition” list does not really make sense if a given word is to appear multiple times in the “dictionary,” such as with the Romeo & Juliet example that he cites.

Indeed, the state of whether each <dt> is unique is oftentimes my deciding factor when I am debating whether to use a definition list or something else, such as headings and paragraphs. The area in which I do not fully agree with the author is his mental jump from:

Listing dialogue is not defining anything…

— To:

Form labels and elements [are] not a good use for a definition list.

It is true that some screen readers, including JAWS, announce “equals” between definition-terms <dt> and definition-descriptions <dd>, but that does not necessarily tell the whole story.

What the author did not mention, or may not have been aware of, is that JAWS also provides an announcement at the beginning of definition lists: “Definition list of X items.” With the addition of that mental cue, I think users of screen readers would be fairly well prepared (and perhaps expecting) to hear “equals” as a delimiter between items which followed that announcement.

That being said, here is how I would go about marking-up the form depicted earlier.

<!-- HTML: Definition List -->
<dl>
  <dt><label for="first-name">First Name</label></dt>
      <dd><input type="text" id="first-name" name="first-name" /></dd>
  <dt><label for="last-name">Last Name</label></dt>
      <dd><input type="text" id="last-name" name="last-name" /></dd>
  <dt><label for="email">Email</label></dt>
      <dd><input type="text" id="email" name="email" /></dd>
  <dt><label for="confirm-email">Confirm Email</label></dt>
      <dd><input type="text" id="confirm-email" name="confirm-email" /></dd>
  <dt><label for="phone">Phone</label></dt>
      <dd><input type="text" id="phone" name="phone" /></dd>
</dl>

Table Elements

So, where do table elements fit in? I see Nathan’s logic of how they hold have some semantic value as well. And, due in part to a particular behavior in JAWS — at least in current and past versions of JAWS — I would not say that tables are inaccessible for organizing form elements.

That particular behavior within JAWS is “Forms Mode.” In can be manually toggled on or off, or in some cases it may be activated automatically (more on that in a bit). Before getting to that, you may be asking, “What is forms mode?” In short, while JAWS is in forms mode, it only announces form elements or form-related elements. So, it would read input fields, radio buttons, check boxes, and so on. It also reads label tags and, of course, submit buttons. What it does not read, however, is everything else. This includes table markup, unordered lists, and so on.

JAWS automatically activates forms mode when the user enters the first form element on a page. So — and you may already see where this is going — even if someone used an non-semantic table for organizing a form, it would not make that much difference to JAWS it most cases.

To be fair, even if JAWS did not have a forms mode, I still would not have grave objections to using a semantic table for organizing form elements. After all, as Nathan contests, a typical form is made up of <label> and form-element pairs that can be made to fit with the way tables work.

Here is Nathan’s tabular markup (cellspacing since IE cannot do CSS border-spacing).

<!-- HTML: Tablular Form -->
<table cellspacing="0">
  <tr>
    <th scope="row"><label for="first-name">First Name</label></th>
    <td><input type="text" id="first-name" name="first-name" /></td>
  </tr>
  <tr>
    <th scope="row"><label for="last-name">Last Name</label></th>
    <td><input type="text" id="last-name" name="last-name" /></td>
  </tr>
  <tr>
    <th scope="row"><label for="email">Email</label></th>
    <td><input type="text" id="email" name="email" /></td>
  </tr>
  <tr>
    <th scope="row"><label for="confirm-email">Confirm Email</label></th>
    <td><input type="text" id="confirm-email" name="confirm-email" /></td>
  </tr>
  <tr>
    <th scope="row"><label for="phone">Phone</label></th>
    <td><input type="text" id="phone" name="phone" /></td>
  </tr>
</table>

My Preference?

In the end, I think I may lean toward definition lists for form elements. I will admit that definition lists would be lousy for this task if a given “term” were to appear more than once within a “list,” but fortunately that is not usually the case with forms. For instance, “credit card expiration date” and other such items typically appear just once per form.

So, why give definition lists the edge, especially with forms mode in play? It is true that forms mode does quite a bit to level the playing field between various semantic philosophies toward form elements. Still, I would be remiss to discount other screen readers. JAWS has a sizable market share, but it is not the only screen reader around. In my opinion, what gives definition lists the edge is the wordiness (or lack thereof) compared to other approaches.

Put another way, it is much slower to listen to some text being read aloud than to read that same text with one’s own eyes. Unfortunately, users who are not sighted do not have that choice and can only discern a page by listening to it. For that reason, I think there may be a usability advantage to users with screen readers if they are able to have a form introduced to them as:

Definition list of five items […]

— Versus:

Table with two columns and five rows. Table header […]

So, that’s my take. I can see some of the reasoning to suggest table elements as one of the options in these types of scenarios, but I think definition lists might just squeak ahead in the end.

Comments on “Forms: Definition Lists or Tables?”

1. Bryan J Busch said:

   The debate is answered for you if you put your input below your label, which also makes for a more mobile-friendly page.

   ---

2. Rogie King said:

   Definition lists are definitely my preference in this death-match.

   From purely a designer/coder standpoint (not necessarily more important), I’d like to see how Nathan styles label and input combos in relation to each other in a table. For instance, label to the right, left, over, under the input or label followed inline to the input.

   As for the folk that use JAWS or some other screenreader, id love to hear their preference…straight from the horses mouth.

   ---

3. Dan Mall said:

   From a markup standpoint, I definitely think both have their merits. I’d say the table method wins out because a screen reader can access the table header from anywhere in the table (I think). It’s one of the only elements that can read reverse relationships.

   However, the table definitely makes certain forms harder to style. Any form with an input and a label on separate lines (Mark Boulton’s comment form, for instance) would take a considerable amount of work with the table markup you’ve shown. And achieving Zeldman’s comment form would be dang near impossible.

   This is the method I prefer:

   <form>
   <ul>
   <li>
   <label for=“field1”>Field 1</label>
   <input type=“text” id=“field1” name=“field1” />
   </li>
   <li>
   <label for=“field2”>Label 2</label>
   <input type=“text” id=“field2” name=“field2” />
   </li>
   </ul>
   </form>

   It’s flexible enough for styling purposes, and I don’t think it detracts from the experience of any user. While the table may contain extra functionality, I’m ok with the tradeoff.

   ---

4. chuck said:

   That’s a good debate. I’m ok with the idea of using the tables, especially given a form that has a label to the left of the input. However, I think the definition list is best for future flexibility and styling considerations. Interesting that Dan Mall would prefer the unordered list above the other two options. Seems to me, the definition list is a bit more semantic in that you can show a relationship between the input and the label.

   Thanks for clarifying these different options and for explaining how JAWS interacts with the code. Very interesting.

   ---

5. Andy Croll said:

   I tend to prefer the method outlined by Cameron Adams in Art and Science of CSS, and given away for free which utilises ordered lists within fieldsets. The standard markup he suggests, gives you plenty of options for form layouts.

   ---

6. Nathan Smith said:

   I guess I should weigh in here. I didn’t mean to imply that forms should always be marked up using tables, simply that in a few specific cases, it makes the most sense from a semantic standpoint. I am glad that Alex wrote this article, because it is always good to challenge our presuppositions, and choose the best possible solution.

   As Bryan pointed out, a table wouldn’t be suitable for a form layout in which fields were positioned visually beneath their labels. I was just trying to point out, that in the particular case of horizontal arrangement, on is in fact creating a tabular relationship.

   I’ll admit that <dl> is probably the way to go, as far as flexibility. This would be especially true in the case of radio buttons or checkboxes, in which a pseudo-label could possibly apply to one or many options. A <dt> could be used for the descriptor, with several subsequent <dd> to contain the multiple checkboxes and/or radio buttons.

   @Andy — Cameron’s method is a good one, but I question the use of an ordered list, since not all forms are necessarily sequential. It would make sense for fieldset groups, but not for the inputs themselves. For instance, a form in which there are required fields dispersed along with optional ones. That being said, Dan Mall’s method is essentially the same as Cameron’s, albeit with a unordered list.

   ---

7. Matthew Pennell said:

   I second Andy Croll’s preference for Cam Adam’s technique in his Sitepoint article. @Nathan – if form elements aren’t sequential, why put them in that order? ;)

   As for the question of semantics, why do we need to add semantic meaning via a definition list or table, when there is already a semantic relationship between a form input and its label? It seems like adding extra markup for no real reason to me.

   ---

8. beth said:

   I tend to go the same route as Dan Mall, but this is definitely an interesting approach! Having the label and input in the same list item is more flexible for me, because I have different classes for different form types which use width to force the label on top of, or allow it to sit beside the field.

   ---

9. Andy Croll said:

   @Nathan: I tended to agree, but on reading the provided arguments showing if you ever look at most official or more complicated forms they tend to be numbered.

   I’m not militant about the use of an ordered list, for shorter forms I might consider an unordered one (or even no list at all for a single search box). However I’d have to say I greatly prefer an unordered list to the use of a definition list, my feeling has been more eloquently described than I can elsewhere on that issue.

   ---

10. Eric Shepherd said:

    I’m with Matthew on this one. I’m currently just using li elements, because there’s already a semantic connection between labels and inputs due to the for=”“ attribute. Adding another set of semantics in the form of the dt – dd pairing seems superfluous. Using a li element will allow most styling scenarios to work. Whether ordered or unordered is up to the individual form – very short forms don’t need to be numbered.

    ---

11. Adam said:

    The BBC web guidelines state “9.5. A label-input pair SHOULD NOT be contained in a <dl>, as this provides no additional structural information.”

    http://www.bbc.co.uk/guidelines/newmedia/technical/semantic_markup.shtml

    ---

12. Kyle Hayes said:

    @Adam, very interesting reference.

    For a couple of years now, this hot topic has often led to the definition lists style from my various readings. But now, that Dan Mall, has pointed out the use of lists and others have mentioned that form elements and labels already have a semantic relationship, I don’t see why lists are not more widely documented as possible solutions.

    To add to that, why not use DIVs? Not giving a reason, I am really just asking.

    ---

13. Nathan Smith said:

    @Kyle — It’s interesting you suggest DIVs, because that’s what a few of my friends had proposed when I asked the question of DL vs. Tables on Twitter. I suppose they’re the most semantically neutral. Depending on the type of form elements, and the purpose of the data collected, that might be a good route to take.

    ---