WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG and form labels

for

From: Jukka K. Korpela
Date: Aug 21, 2006 11:30AM

On Mon, 21 Aug 2006, Jared Smith wrote:

> I received a question that came in from our site about WCAG 1.0 and
> form labeling. There are two checkpoints that address this. 12.4
> required explicit labels (using for/id association).

Not quite. It says:
"Associate labels explicitly with their controls. [Priority 2]
For example, in HTML use LABEL and its "for" attribute."

The "For example - -" part can be read as an example, which does not
exclude the use of LABEL without "for".

The wording is somewhat unfortunate, since the word "explicitly" is rather
implicit here. What it means is simply "in markup", as opposite to visual
association. Someone might get confused, since from the user perspective,
there is nothing very explicit in the association via markup.

> 10.4 required
> implicit form labeling (surrounding the form control with the label
> element) UNTIL USER AGENTS supported explicit labeling (using for and
> id to associate the control with the label).

Why the past tense? The checkpoints are still there. Whether their
conditions are true is partly clear (though not to all) but partly rather
obscure and debatable.

Anyway, 10.4 says no such thing. It says: "Until user agents handle empty
controls correctly, include default, place-holding characters in edit
boxes and text areas." It's an originally wrong rule, it's certainly
outdated now (with its condition as false as can be), but it has nothing
to with form labels.

Checkpoint 10.2, on the other hand, says:
"Until user agents support explicit associations between labels and form
controls, for all form controls with implicitly associated labels, ensure
that the label is properly positioned. [Priority 2]
The label must immediately precede its control on the same line (allowing
more than one control/label per line) or be in the line preceding the
control (with only one label and one control per line)."

It's _not_ about the LABEL element but about positioning (placement) of
fields and their labels. Granted, it says "with implicitly associated
labels", but this is very obscure. It probably refers to fields (controls)
that have no LABEL markup associated with them, but this would mean an
internal contradiction in WCAG 1.0, since Checkpoint 12.4, at the same
"priority level", prohibits such fields!

Putting this mess aside, from the real accessibility point of view (as
opposite to meeting "accessibility criteria"), the principle in 10.2
_should_ be applied to fields in general, with no reservations regarding
browser development or the use of LABEL elements. The point is that
visually obvious association is relevant to a huge number of users. It may
be irrelevant to people using nonvisual browsers that have good support to
LABEL elements, but it does no harm to them.

> My interpretation of 1.0
> is that explicit labeling should ALWAYS be used.

That's correct. Checkpoint 12.4 says it explicitly. The remaining question
is what "explicit labeling" means. Contrary to good accessibility
principles, WCAG 1.0 does not specify this. It is fair to assume that the
use of LABEL according to HTML specifications is sufficient for this.

You seem to think that

<label for="foo">xxx</label> <input id="foo" ...>

is explicit whereas

<label>xxx <input id="foo" ...> </label>

is implicit. But I think this is not the kind of explicit vs. implicit
distinction that the WCAG 1.0 makes but a completely different
distinction, though it too uses words confusingly. Both methods mean that
the association is made in markup. The difference is technical. Some
browsers support the latter but not the former. On the other hand, the
former is more logical (an input field is logically not part of its
label!), and it is the only approach that applies when e.g. you have the
label in one cell of a table, the input field in another.

The WCAG 1.0 might be seen as favoring the first method, due to the
wording of 12.4. But it's mostly a practical choice. In teaching people,
it might be best to teach the first method only, to keep things simple.

(The requirement itself is not adequate in its strict formulation.
In particular, submit buttons seldom need any labels; they "label
themselves". But I suppose most accessibility specialists silently make
this exception to the rule.)

> In researching, I found the WCAG 2.0 documentation -
> http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20050630/#label
> - that again states that explicit labeling should always be present.

WCAG 2.0 is sketchy draft and will remain that way for a long time if not
indefinitely. It may be useful reading - this particular clause surely is
in this context, up to and excluding the point where it starts confusing
things with reference to "implicit label" - but it has no authoritative
status. It itself says: "It is inappropriate to cite this document as
other than work in progress."

--
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/