E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Jared Smith
Date: Mon, Aug 21 2006 10:30AM
Subject: WCAG and form labels
No previous message | Next message →

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). 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). My interpretation of 1.0
is that explicit labeling should ALWAYS be used. I believe that
implicit labeling is no longer required under the "until user agents"
clause. Do you agree?

This meant that before the "until user agents" part was fulfilled, the
only way to meet WCAG 1.0 was to use for/id AND to surround the
control with the label element, right?

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.
Great! It also states that implicit association is deprecated and
should NOT be used. So if my interpretation is correct, then a construct
like the following is not allowed in WCAG 2.0:

<label for="firstname">First Name
<input type="text" id="firstname">
</label>

In looking at the examples, it would appear this is implicit labeling
and as such is deprecated and shouldn't be used. I'm just wondering if
others have the same interpretation and if they think this is correct
or not. This is method that is prescribed by loads of accessibility sites.
It is also what was originally required by WCAG 1.0. So, either the WCAG
2.0 documentation needs to be changed or else we need to stop using this
method. Or maybe I'm missing something.

Jared Smith
WebAIM.org

From: Andrew Kirkpatrick
Date: Mon, Aug 21 2006 11:10AM
Subject: RE: WCAG and form labels
← Previous message | Next message →

Jared,
Your example below is explicitly labeled. I've always thought that if
you wrap a label around a control that it sould count as explicit, but
it doesn't unless the for/id are used. When they are used you have
explicit labeling. If WCAG 2.0 disallows this I'd be very surprised and
would lobby against this, since it works and also has benefits for
styling forms (applying css rules to the label element such as label
{display:block;} )

AWK

> 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.
> Great! It also states that implicit association is deprecated
> and should NOT be used. So if my interpretation is correct,
> then a construct like the following is not allowed in WCAG 2.0:
>
> <label for="firstname">First Name
> <input type="text" id="firstname">
> </label>
>
> In looking at the examples, it would appear this is implicit
> labeling and as such is deprecated and shouldn't be used. I'm
> just wondering if others have the same interpretation and if
> they think this is correct or not. This is method that is
> prescribed by loads of accessibility sites.
> It is also what was originally required by WCAG 1.0. So,
> either the WCAG 2.0 documentation needs to be changed or else
> we need to stop using this method. Or maybe I'm missing something.
>
> Jared Smith
> WebAIM.org
>
>
>
>
>

From: Jukka K. Korpela
Date: Mon, Aug 21 2006 11:30AM
Subject: Re: WCAG and form labels
← Previous message | Next message →

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/

From: Jared Smith
Date: Mon, Aug 21 2006 12:00PM
Subject: Re: WCAG and form labels
← Previous message | Next message →

Andrew Kirkpatrick wrote:
> Jared,
> Your example below is explicitly labeled. I've always thought that if
> you wrap a label around a control that it sould count as explicit, but
> it doesn't unless the for/id are used. When they are used you have
> explicit labeling.

But does this mean that implicit and explicit labeling are mutually
exclusive? If they are not, and you use for/id and also wrap the label
element around the form control, is this ALSO implicit. If it is, then
according to the documentation, it is deprecated and shouldn't be used.
The WCAG 1.0 documentation uses this approach and clearly calls it
implicit - http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels

Based upon this and upon the WCAG 2.0 examples, I have to assume that
wrapping the label around the form control is deprecated, regardless of
whether explicit labeling is used.

> If WCAG 2.0 disallows this I'd be very surprised and
> would lobby against this, since it works and also has benefits for
> styling forms (applying css rules to the label element such as label
> {display:block;} )

And this begs the question of whether the form control is (or should be)
part of the label for itself. I believe this is the motivation for the
deprecation of implicit labels. Semantically, it just doesn't make sense
that the form element be part of the label for itself. On the other hand,
it's a widely used practice and one that was recommended in WCAG 1.0.

This is really why I'm wondering if others are as confused as I am about
it. If so, then we need to ask the WCAG 2.0 group for some clarification.

Jared Smith
WebAIM.org

From: Jared Smith
Date: Mon, Aug 21 2006 12:20PM
Subject: Re: WCAG and form labels
← Previous message | Next message →

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

From: Andrew Kirkpatrick
Date: Mon, Aug 21 2006 2:00PM
Subject: RE: WCAG and form labels
← Previous message | No next message

> But does this mean that implicit and explicit labeling are
> mutually exclusive? If they are not, and you use for/id and
> also wrap the label element around the form control, is this
> ALSO implicit. If it is, then according to the documentation,
> it is deprecated and shouldn't be used.
> The WCAG 1.0 documentation uses this approach and clearly
> calls it implicit -
> http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels

My reading is that it is implicit _because_ there is not a for/id.
Adding the for/id makes it explicit. There are multiple ways to make
implicit labeling - positioning, label-wrapping, but only by using
for/id (or you can use a title attribute, in my opinion since the title
attribute is permanently associated) can you get it to be explicit.

It isn't implicit because the label is wrapped, it is implicit because
it is not explicit and because the developer goes and tests to ensure
that it works. They are mutually exclusive.

> Based upon this and upon the WCAG 2.0 examples, I have to
> assume that wrapping the label around the form control is
> deprecated, regardless of whether explicit labeling is used.

I'd disagree. There's no good reason to "deprecate" this technique. It
works, it is explicit - we can argue about the semantic purity of it
until WCAG 3.0 is out but it is an acceptable technique.

AWK