WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG and form labels

for

From: Jared Smith
Date: Aug 21, 2006 12:20PM

Jukka K. Korpela wrote:

> 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.

Yep. It is 10.2 that I meant to refer to.

> 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!

Precisely the reason for my confusion. And to add to this, the examples
show nothing about positioning, but only present implicit labeling and the
label element.

> 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.

I agree. The visual positioning if vital. But again, the wording of 1.0
seems to indicate that once explicit labeling is supported, then the
positioning doesn't matter at all. But that's not really relevant here.

> 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.

Perhaps that is the case with 1.0, but 2.0 clearly states (at least, it's
clear to me) that if you wrap a form element with the label tag, it is
implicit and you shouldn't do this.

> (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.)

Thankfully WCAG 2.0 does make this clarification. Though in it's
explanation of this, it states that explicit labels aren't required "since
they have labels *implicitly* associated via their value or alt
attributes" which again makes you wonder what they mean by "implicit". The
confusion increases!

> 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."

Yep. And I hope our discussions can be used to improve that work in progress.

Jared Smith
WebAIM.org