A few months ago, I logged out of my account the American Express website before remembering another task I needed to do, so I clicked the “Log Back In” button they so conveniently displayed. Strangely, the login form I was presented didn’t look the same as the one I was used to seeing on the American Express homepage. This new form had some strange black squiggles above each field.

What the heck are those squiggles? I wondered. A Control-click later, I had inspected one of the squiggles and discovered that it was actually tiny text, the contents of a not-quite-hidden legend element. I wasn’t surprised with my discovery, after all, most accessibility-aware coders have been using legends (and their necessary parent fieldsets) to organize form controls for years. What was different about this implementation was that every field in the form was wrapped in its own fieldset with its own legend. And, as if that wasn’t bizarre enough, each legend contained the same text: “Log In to American Express Online Services”.

Normally, I applaud the use of rich semantics like legend and fieldset as they provide excellent means by which to organize complex forms. But looking at this form, I surmised that the author knew enough to understand the importance of these elements, but wasn’t really sure how to go about implementing them. It’s the classic well-meaning but misguided markup trap we’ve all fallen into at one time or another. Either that, or American Express’ CMS was suffering from some form of markup-based Tourette’s.

Getting organized

Before we dive into alternative markup approaches, let’s take a quick look at the HTML behind this form. Here’s a brief excerpt:

<div><font class="smalltext"><strong>User ID</strong></font></div>
<div>
  <fieldset class="fieldSetStyle">
    <legend class="hideLegend hideLegendIE7">Log In to American Express Online Services</legend>
    <input maxlength="32" name="UserID" size="20" title="Enter the User Id" value="" onchange="uncheckRememberMe()" height="1">
  </fieldset>
</div>
<div>
  <fieldset class="fieldSetStyle">
    <legend class="hideLegend hideLegendIE7">Log In to American Express Online Services</legend>
    <input title="Remember My User ID" name="REMEMBERME"  type="checkbox" class="checkBox" checked>
    <font class="smalltext"><strong>Remember Me</strong></font>
  </fieldset>
</div>

Yeah, I know, the author is using a font element, but let’s table that discussion as I want to focus on fieldset and legend.

Despite looking quite similar, the version of the login form that appears on the American Express homepage uses no fieldsets at all and, apart from the names used for each of the form fields, bears little resemblance to the over-fieldset-ed form. Here’s a brief excerpt of these same fields in that form:

<div class="labelsfont "><strong>User ID</strong></div>
<!-- skipping some hidden fields -->
<input tabindex="41" class="txtSize" type="text" id="UserID" title="This is the User ID text field where you enter your User ID to login" name="UserID" size="20" onkeypress="return submitenter(this,event)"/>
<div>
  <input tabindex="51" type="checkbox" title="Check this box to have the American Express website securely remember and store your User ID on the computer you are currently using" name="REMEMBERME" onclick="javascript:RmbrChkBox();"/>
  <span class="blkcolorClass ">Remember Me</span>
</div>

The differences between the two forms lead me to believe the forms were either built by two separate departments or built at two very different times by the same department. The fact that one is written as HTML and the other is serialized as XHTML only reinforces that hypothesis. The inconsistencies between the two are problematic for many reasons, but I’ll get to that discussion in a moment.

Obviously, this form is much more condensed, but it suffers from similarly poor markup practices. However, before we jump in and start refactoring the markup of these two forms, let’s quickly review the raison d’être of fieldset and legend elements:

The FIELDSET element allows authors to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible.

The LEGEND element allows authors to assign a caption to a FIELDSET. The legend improves accessibility when the FIELDSET is rendered non-visually.

Looking at the markup of the fieldset-ed form, I think the author was on the right track, just a bit overzealous. If we took his fieldset and legend and, instead of using it to wrap the individual fields, used it to wrap the contents of the form as a whole, I think that’d be a win for everyone:

<fieldset class="fieldSetStyle">
  <legend class="hideLegend hideLegendIE7">Log In to American Express Online Services</legend>
  <!-- form contents will go here -->
</fieldset>

Of course some might argue, as Derek does, that this form is a too basic for a fieldset and legend to be all that helpful, despite being semantically correct. It’s a matter of preference, but if you decide to use the fieldset/legend construct, I would suggest a shorter legend; perhaps, simply, “Log In.”

With the fieldset wrapper in place, the individual form controls and other associated content can be flowed in. Personally, my preference is to use an ordered list (ol) to contain each form control in a collection of several (as we see in this login form), but if you have a penchant for p or div elements, that’s cool too; as long as your content is organized and makes sense both visually and aurally, the choice is yours:

<fieldset class=“fieldSetStyle”>
  <legend class="hideLegend hideLegendIE7">Log In to American Express Online Services</legend>
  <ol>
    <li>
      <font class="smalltext"><strong>User ID</strong></font>
      <input maxlength="32" name="UserID" size="20" title="Enter the User Id" value="" onchange="uncheckRememberMe()" height="1">
    </li>
    <li>
      <input title="Remember My User ID" name="REMEMBERME"  type="checkbox" class="checkBox" checked>
      <font class="smalltext"><strong>Remember Me</strong></font>
    </li>
    <!-- more form content goes here -->
  </ol>
</fieldset>

To label or not to label

If you’re like me, another aspect of the markup that isn’t sitting quite right with you is the lack of label elements surrounding the visual labels for the form (e.g. “User ID”). Surely the label element is more meaningful than font and strong? Of course it is, but it’s worth explaining the approach the authors are using here: they have opted to use title attributes on the form controls rather than label elements. As you probably know, the title attribute provides advisory information about the element it is applied to, which certainly makes it a valid choice for form controls.

When a screen reader encounters a form control, it looks to see if the document contains a label associated with that control. If it finds one, the contents of that label are read aloud; if it does not find one, it will look to see if the control has a title attribute. If it finds a title, that text is read aloud in lieu of a label. This may very well be the reason the author of these forms chose not to use label elements.

It’s certainly a valid method that lines up with the recommendations of WCAG2, but, from my perspective, the label element would be preferable because labels benefit both sighted and non-sighted users alike. They are not only visible and clickable by sighted users, but are made available to non-sighted users when the related form control is focused. The title attribute, in contrast, is only exposed to sighted users as a tooltip when the form control is moused over, meaning that if you want to ensure a sighted user can read that content, you have to include it via a secondary method—as the authors of this form have within the font > strong combo. That sort of redundancy doesn’t sit well with me because I don’t feel that “Enter the User Id” (the contents of the title attribute) provides any more context to non-sighted users than “User ID” would if it were a label. For that reason, I’d simplify the markup and drop the title attributes:

<fieldset class="fieldSetStyle">
  <legend class="hideLegend hideLegendIE7">Log In to American Express Online Services</legend>
  <ol>
    <li>
      <label class="smalltext" for="UserID">User ID</label>
      <input maxlength="32" id="UserID" name="UserID" size="20" value="" onchange="uncheckRememberMe()" height="1">
    </li>
    <li>
      <label class="smalltext">
        <input name="REMEMBERME"  type="checkbox" class="checkBox" checked>
        Remember Me
      </label>
    </li>
    <!-- more form content goes here -->
  </ol>
</fieldset>

As you can see, each form control has its own label element. In the case of the “User ID” field, the label is explicitly associated with the form control using the for attribute (which references the id of the associated form control). In the case of the “Remember Me” checkbox, the label is implicitly associated because it contains that input, demonstrating the alternate method of label-control association. It’s worth noting that explicit association is generally preferred if you need to support legacy browsers like IE6, but you can always assign the for attribute to a label that is using implicit association as a back-up.

<fieldset>
  <legend>Log In to American Express Online Services</legend>
  <label for="UserID">User ID</label>
  <input id="UserID" name="UserID">
  <label for="pass">Password</label>
  <input type=”password” id="pass" name="pass">
</fieldset>