The WHATWG Blog

Please leave your sense of logic at the door, thanks!

fieldsets need legends

by Gregory Rosmaita in Forms, WHATWG

this post refers to the "Write" interface from WordPress utilized to post comments to WHATWG blogs.

there is well-intentioned, but mis-implemented markup in the edit form; namely, improper implemetation of the FIELDSET.

for a proper FIELDSET, one needs to do 4 things:

  1. open the FIELDSET (which this form does)
  2. define a LEGEND for the FIELDSET (which this form does NOT); the natural candidates for LEGEND are the level 3 headers (H3) classed dbx-handle so instead of repeatedly hearing "click to open this box", i would also get the pseudo-box (which i would call sub-forms) LEGEND as an indicator of what i am about to open or close. i would also make the alt text device independent - instead of "click here to open this box", i would propose "show sub-form" and "hide sub-form"
  3. bind individual FORM controls to their textual labels by use of the LABEL element and the for/id mechanism that ties the form control (which takes the "id") to a LABEL (which takes the "for") or multiple labels; the LABEL should contain the actual, textual label, and NOT the FORM control, as in this form; this form has the attribute set set correctly to bind the LABEL to the FORM control, but since the LABEL element is opened PRIOR to the INPUT element, no labeling is available to the user - in my case (i use a screen-reader) the sub-forms that appear when one opens a FIELDSET to reveal a FORM appear unlabeled to my screenreader, because of invalid markup.
  4. close the FIELDSET (which this form does)

↔

10 Responses to “fieldsets need legends”

  1. I’ve always found that legend tag a bit weird. It’s like an attribute, because it’s position in the fieldset doesn’t matter, but it accepts html, so it can’t be an attribute.

  2. Er… Legend might become optional in HTML5 (it’s not specced yet). It is also perfectly fine to use parent-child relationship between the label and form control (even in HTML4). What did you base your assertions on?

  3. Is there any reason you do not use capital letters for the start of your sentences?

  4. What’s invalid about associating labels to controls by nesting the control inside the label? (Other than that it doesn’t work in IE.) The HTML 4.01 spec clearly states

    To associate a label with another control implicitly, the control element must be within the contents of the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control.

  5. Nesting controls inside labels (implicit association) isn’t invalid, but it also isn’t best practice. To make sure all user agents can associate each label with its corresponding control, both WCAG 1 and the WCAG 2 Working Draft require using the for and id attributes instead (explicit association). An added bonus is that doing so will give you better styling options.

  6. About fieldset legends, I agree in theory. In the real world, however, legend is one of those HTML tags that are impossible to style consistently across different browsers with CSS. So many web sites that use fieldsets may be avoiding the use of legends.

    About labels, implicitly associating labels with controls by nesting is prefectly valid, and there is no technical reason whatsoever that a screen reader (or any other user agent) wouldn’t be able to handle that. In fact, if it doesn’t handle it, it’s broken.

    WCAG 1 actually recommends nesting controls in inputs. And which option gives you “better” styling options really depends on what you need.

    Personally, I try to avoid explicit label associations whenever I can (which means, pretty much always when outside of a table). Having to manage IDs always adds overhead, because you need to pay attention to keeping them unique. And of course they require more typing and more bytes on the wire. Having to use IDs for every tiny form control just to bind labels to them would be insane in my opinion.

  7. The fieldset and legend tags are 2 of the most annoying things to try to style.

    By default the Legend shows as breaking halfway through the border of the fieldset. Sure this makes it look more like it’s counterparts in desktop appications/windows installation wizards but….doesn’t that breaks the rules of the box model!

    If a parent element is set to overflow:hidden then any portion of any child element outside of the area of the parent element will be invisible, yet the legend on a fieldset with overflow:hidden has half of itself outside of its parent and is SOMEHOW still entirely visible. It makes no sense. It breaks the rule.

  8. zimbatm, as to why LEGEND is an element?

    1. so it can have children. take, for example, the “Reply to this Comment” FORM, which i am currently using to respond to your comments; it’s a simple form – a single fieldset, in fact. due to the lack of a LEGEND, when i reach the TEXTAREA, depending upon which of the 3 screen readers at my disposal, i hear either: “unlabeled edit box”, “textarea”, or the nearest string of text, which in this case is the nonsensical “XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong> “.

    so, a FIELDSET contains a related grouping of form controls, each one of which needs to be individually labeled. the LEGEND allows a non-visual visitor’s assistive technology to contextualize the FORM controls bound to the LEGEND, by virtue of their inclusion in the FIELDSET, currently, on this site, a level 3 header (H3) is used as an ersatz LEGEND, which only works as a LEGEND when processed visually, due to its styling, and its identification as a header.

    there is no way for an assistive technology to associate the nearest header with a form control grouping, unless that header also serves as the LEGEND for the FIELDSET of FORM controls that allow one to “Reply to this Comment”.(that, and headers are important for structure and navigation, and it is fitting to use a LEGEND as a header.


    <FIELDSET>

    <LEGEND><h3>Reply to this Comment</h3></LEGEND>

    <LABEL for="textarea1">Note: <strong>XHTML</strong>: XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong></LABEL>

    <INPUT TYPE="textarea"> id="textarea1" >

    <INPUT TYPE="submit" value="Submit Reply"/>

    </FIELDSET>

  9. About labels, implicitly associating labels with controls by nesting is prefectly valid, and there is no technical reason whatsoever that a screen reader (or any other user agent) wouldn’t be able to handle that. In fact, if it doesn’t handle it, it’s broken.

  10. From the CSS point of view, I don’t like fieldset that much. So I don’t use them that often. But if you were referring the legend as a separator within forms, you could in fact use the header-tags. This is valid and so much more skinable.

    Labels are very much stylable and can be used to label a form-field by means of text, or as wrapper for this form-field. Both are perfectly valid and depends on peoples creativity to use one or the other.

    About nesting? Avoid them in forms. That was not the purpose from the start. Forms only need controls. And depending on your CSS skills you will start to use the right html-tag for the right purpose.

    Conclusion: It’s a good article but I personally would recommend the legend tag that much. Simple reason that you can use stylable tags that even feel more logic.