WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: label element


From: Leo Smith
Date: Apr 4, 2002 10:08AM


Thanks for taking the time to respond to my postings with a very
detailed reply.

The periods before the elements' tags where so that they would not
be marked up by an email client...some others have been doing
this on the list for this reason - I should have stated that was the
reason in my posting.

As far as <label> being a child of the <form> element, Paul and
Jim have noted on the list that the specs say the <label> element
can exist outside of the form element.

The other info you provide helps to clear up in my mind the correct
coding sequences when it comes to <form>, <table>, <tr> and



On 3 Apr 2002, at 23:21, Terence de Giere wrote:

> Leo
> I did not quite understand your code sample for FORM elements because
> on the forum message there were periods before the element names
> within the start tags and end tags. Also there was a LABEL outside of
> the FORM, which is not allowed in HTML.
> The FORM element must encapsulate all other FORM child elements for
> that FORM. A FORM element cannot be placed inside another FORM
> element.
> A common error has to do with the use of tables. The TABLE element or
> several TABLE elements may be placed inside a FORM element. With the
> older HTML specifications, TABLE elements can be nested, with a new
> TABLE inside a cell of first TABLE. A FORM element and all its child
> elements may be placed in a single TABLE cell, either TH or TD, but
> the FORM element cannot be placed in any other place in a table, such
> as between rows or between cells etc., and although some browsers
> support this, this is not legal HTML, and will create problems for
> technology that does support official HTML specs.
> Also, except for the FORM element itself, a TABLE may not be placed
> inside any other FORM child element. No official HTML specification
> allows this. HTML 4.01 also requires that the LABEL element be a child
> of some other element directly in the FORM element, for example, a P
> element or a DIV element, or ideally the FIELDSET element, which
> allows grouping related controls. Also the FIELDSET element has a
> child element LEGEND, which can give an explanation for the group of
> controls in the FIELDSET, which is supported by some assitive
> technology. Placing the LABEL directly in the FORM element, that is,
> right after the FORM element violates the official HTML
> specifications. The legal elements that can be placed immediately
> after the FORM element are (in HTML 4.01) ADDRESS, BLOCKQUOTE, DEL,
> SCRIPT, TABLE, and UL. One of these must be used as a container for
> first FORM control or controls and their LABELs. Remember that TABLE
> must also have a TR with a TH or TD child before using another FORM
> child element.
> Thus one could have a FORM, place a TABLE in the FORM, and place the
> child elements of the form inside TABLE cells. Avoid putting the LABEL
> element in a row above (before) the row that contains the form input
> or control it is associated with, since, unless the table has just one
> column, it becomes disassociated from the control as the screen reader
> or audio browser will continue to the end of that row before
> proceeding to the next row. So if tables are used, you can place the
> LABEL in the cell in the same table row immediately preceeding the
> cell that contains the control. You can also place the LABEL in the
> same cell as the control, preferably before the control. This is to
> maintain a read order that works if the technology does not support
> the explicit association using the "for" attribute.
> You may also place the form control inside the LABEL element with the
> LABEL text preferably before the control. This is an implicit
> association. When using an implicit association, you cannot use the
> LABEL in a separate TABLE cell because that would involve incorrectly
> nested elements. This implicit association also allows the possibility
> for visual CSS format to surround both the control and the LABEL text
> with some sort of format that visually will show that the LABEL text
> and the control "go together" for users with normal vision or visual
> impairment that may only require moderate magnification to see well.
> Also with regard to some less used special access technology, format
> TABLEs can be a usability barrier because some or all of the
> structures of the TABLE are are announced or read out to the user,
> interpolating a lot of useless information the user does not need to
> hear, or feel.
> Terence de Giere

Leo Smith
Web Designer/Developer
USM Office of Publications and Marketing
University of Southern Maine

To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/