E-mail List Archives

Search E-mail List Archives for

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

From: Neier, Garrett
Date: Fri, Jul 01 2011 8:12AM
Subject: Re: label element containing input element
No previous message | Next message →

Hi All,
This issue was last discussed in 2003. The advice then was to separate the <label> from the form element.
Today, it appears that the technique of enclosing the form element in the <label> is more widely used and part of the spec.
Does anyone know if today's screen readers can handle it?

Example:
<label>
Enter text
<input type=text id=firstname>
</label>

http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL
from
http://stackoverflow.com/questions/774054/should-i-put-input-tag-inside-label-tag

I ask because I would like to create the cleanest html, without resorting to <br> tags between elements.
The only example I found, without <br> tags, has <label> containing the element
http://www.themaninblue.com/experiment/InForm/margin.htm

thank you,
Gary

From: Jared Smith
Date: Fri, Jul 01 2011 8:51AM
Subject: Re: label element containing input element
← Previous message | Next message →

On Fri, Jul 1, 2011 at 8:12 AM, Neier, Garrett < = EMAIL ADDRESS REMOVED = > wrote:
> Hi All,
> This issue was last discussed in 2003.  The advice then was to separate the <label> from the form element.
> Today, it appears that the technique of enclosing the form element in the <label> is more widely used and part of the spec.
> Does anyone know if today's screen readers can handle it?

Most screen readers properly handle implicit labeling (placing the
form control within the label element). I've always been a bit
uncomfortable with this because it's semantic nonsense - the control
is part of the label for itself? Nothing else in HTML works like this.

At one point the W3C recommended against implicit labeling, but now I
see that it is the standard format in HTML5.

Using explicit (matching for/id attribute values) is a bit more
bulletproof - it works even if the form controls are not adjacent or
if they are moved around in markup. It avoids all possible ambiguity
as to which label goes with which control.

What you must avoid is using for/id AND wrapping the form control. For
some reason most screen readers do not make any association in this
case.

Jared Smith
WebAIM.org

From: Michael.Moore@dars.state.tx.us
Date: Fri, Jul 01 2011 9:15AM
Subject: Re: label element containing input element
← Previous message | Next message →

Jared wrote: "What you must avoid is using for/id AND wrapping the form control. For some reason most screen readers do not make any association in this case."

Well isn't that special; associate a label twice and you get nothing. You've got to love the AT vendors. </sarcastic rant> Actually this may help explain some of the weirdness we see at times. Thanks

Mike Moore

From: steven
Date: Fri, Jul 01 2011 9:33AM
Subject: Re: label element containing input element
← Previous message | Next message →

Jared, I agree that "placing the form control within the label element" is
semantic nonsense, but so long as HTML/5 continues to places tags in tags
(there seems to be no getting away from placing links within paragraphs for
example), I actually prefer for form elements to be within labels simply
because there is very good support for it as such (and I strongly believe
true accessibility is as much about backwards compatibility as it is about
future compatibility - long live plain text files).

I personally would love nothing more than for browsers to handle truely
semantic content and actually see web pages move controls and navigation
into the browser itself (or even be moved into a non-content layer) but
looking at the short steps HTML5 has made since XHTML I don't see there
being a big hurry for this. We're still wrapping and duplicating content
(albeit with more semantically named tags), mixing content with function
(why oh why do we still place menus and links within a document!?) ... we
haven't learned much in my opinion with HTML5 as we're still delivering more
than the content that is required in most cases and that is the
responsibility of habit I guess.

Thanks for the tip about the for/id too ... I must investigate that some
more.

Steven



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: 01 July 2011 15:52
To: WebAIM Discussion List
Subject: Re: [WebAIM] label element containing input element

On Fri, Jul 1, 2011 at 8:12 AM, Neier, Garrett < = EMAIL ADDRESS REMOVED = > wrote:
> Hi All,
> This issue was last discussed in 2003.  The advice then was to separate
the <label> from the form element.
> Today, it appears that the technique of enclosing the form element in the
<label> is more widely used and part of the spec.
> Does anyone know if today's screen readers can handle it?

Most screen readers properly handle implicit labeling (placing the
form control within the label element). I've always been a bit
uncomfortable with this because it's semantic nonsense - the control
is part of the label for itself? Nothing else in HTML works like this.

At one point the W3C recommended against implicit labeling, but now I
see that it is the standard format in HTML5.

Using explicit (matching for/id attribute values) is a bit more
bulletproof - it works even if the form controls are not adjacent or
if they are moved around in markup. It avoids all possible ambiguity
as to which label goes with which control.

What you must avoid is using for/id AND wrapping the form control. For
some reason most screen readers do not make any association in this
case.

Jared Smith
WebAIM.org

From: David Dorward
Date: Fri, Jul 01 2011 9:45AM
Subject: Re: label element containing input element
← Previous message | Next message →

On 1 Jul 2011, at 15:12, Neier, Garrett wrote:
> This issue was last discussed in 2003. The advice then was to separate the <label> from the form element.
> Today, it appears that the technique of enclosing the form element in the <label> is more widely used and part of the spec.
> Does anyone know if today's screen readers can handle it?

As far as I know, the problem was (and still is) Internet Explorer 6, not screen readers themselves.

> I ask because I would like to create the cleanest html, without resorting to <br> tags between elements.
> The only example I found, without <br> tags, has <label> containing the element
> http://www.themaninblue.com/experiment/InForm/margin.htm

There is no reason the control has to be inside the label for that. You get most of the effect with a simple:

label {
float: left;
clear: left;
width: <length>
}

But that, and the example you found, suffers badly if CSS is not available, so I would still add some markup that would render new lines by default (wrapping label/control pairs in divs usually).

--
David Dorward
http://dorward.me.uk

From: Neier, Garrett
Date: Fri, Jul 01 2011 12:51PM
Subject: Re: label element containing input element
← Previous message | Next message →

Hi David, Steven, Jarad,
Thank you for the quick feedback. If w3c and screenreaders support labels wrapping the controls, I'll use it. It makes the html/css lighter.
If curious, this is what I came up with .. its as simple, and free of extraneous markup as I can make it - while sticking to the provided design.

http://jsfiddle.net/7h6Yg/

-Gary

From: Steve Faulkner
Date: Mon, Jul 04 2011 12:57PM
Subject: Re: label element containing input element
← Previous message | Next message →

Hi Jared, decided to do some testing after reading this thread:

HTML5 Accessibility Chops: form control labeling
http://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-form-control-labeling/

regards
Stevef

On 1 July 2011 15:52, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Fri, Jul 1, 2011 at 8:12 AM, Neier, Garrett < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi All,
> > This issue was last discussed in 2003. The advice then was to separate
> the <label> from the form element.
> > Today, it appears that the technique of enclosing the form element in the
> <label> is more widely used and part of the spec.
> > Does anyone know if today's screen readers can handle it?
>
> Most screen readers properly handle implicit labeling (placing the
> form control within the label element). I've always been a bit
> uncomfortable with this because it's semantic nonsense - the control
> is part of the label for itself? Nothing else in HTML works like this.
>
> At one point the W3C recommended against implicit labeling, but now I
> see that it is the standard format in HTML5.
>
> Using explicit (matching for/id attribute values) is a bit more
> bulletproof - it works even if the form controls are not adjacent or
> if they are moved around in markup. It avoids all possible ambiguity
> as to which label goes with which control.
>
> What you must avoid is using for/id AND wrapping the form control. For
> some reason most screen readers do not make any association in this
> case.
>
> Jared Smith
> WebAIM.org
>

From: Chris Hoffman
Date: Wed, Jul 13 2011 5:24PM
Subject: Re: label element containing input element
← Previous message | No next message

Those tests are great, Steve. Thanks.

It looks like Chrome fails across the board, and I noticed that the bug report is dated _February_ 4. Is it mislabelled, or did you file it five months ago and nobody has touched it yet?

In any case, do you think we should be using @for _and_ @aria-labelledby, or is that asking for a whole 'nother pile of worms to fall into our laps?

Chris



On Jul 4, 2011, at 2:58 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Jared, decided to do some testing after reading this thread:
>
> HTML5 Accessibility Chops: form control labeling
> http://www.paciellogroup.com/blog/2011/07/html5-accessibility-chops-form-control-labeling/
>
> regards
> Stevef
>
> On 1 July 2011 15:52, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On Fri, Jul 1, 2011 at 8:12 AM, Neier, Garrett < = EMAIL ADDRESS REMOVED = > wrote:
>>> Hi All,
>>> This issue was last discussed in 2003. The advice then was to separate
>> the <label> from the form element.
>>> Today, it appears that the technique of enclosing the form element in the
>> <label> is more widely used and part of the spec.
>>> Does anyone know if today's screen readers can handle it?
>>
>> Most screen readers properly handle implicit labeling (placing the
>> form control within the label element). I've always been a bit
>> uncomfortable with this because it's semantic nonsense - the control
>> is part of the label for itself? Nothing else in HTML works like this.
>>
>> At one point the W3C recommended against implicit labeling, but now I
>> see that it is the standard format in HTML5.
>>
>> Using explicit (matching for/id attribute values) is a bit more
>> bulletproof - it works even if the form controls are not adjacent or
>> if they are moved around in markup. It avoids all possible ambiguity
>> as to which label goes with which control.
>>
>> What you must avoid is using for/id AND wrapping the form control. For
>> some reason most screen readers do not make any association in this
>> case.
>>
>> Jared Smith
>> WebAIM.org
>>