mailed the WG for input http://lists.w3.org/Archives/Public/public-html/2013Jul/0007.html

related twitter discussion https://twitter.com/codepo8/status/353284552397045760

I agree that a label which does not label a control (either by wrapping or explicit association) should be an error.

Use of the element would imply its purpose is to label something - that is we can infer some author intent - so if it does not in fact do so I think it's fair to say it's an author error. 

To think of it another way, if that slipped through in my code I'd want to get an error :)

(In reply to comment #3)
> I agree that a label which does not label a control (either by wrapping or
> explicit association) should be an error.
> 
> Use of the element would imply its purpose is to label something - that is
> we can infer some author intent - so if it does not in fact do so I think
> it's fair to say it's an author error. 
> 
> To think of it another way, if that slipped through in my code I'd want to
> get an error :)

yeah i think so too, what about the use here as a secondary label?

example primary label = accessible name, auxiliary label = accessible description
 
<p><label>name <input type"text" aria-describedby="instructions"></label></p>
<p><label id="instructions">last name only please</label></p>

Yes I think multiple labels should be valid (I'm sure I recall seeing that documented as valid prior to html5). 

Have seen that exact use case actually - additional/long descriptions, hints, error states etc on form inputs with an existing shorter label.

Sorry should have said multiple *correctly-associated* labels :)

I'd prefer to use multiple labels with for="foo" than two different methods of association; that is, that use case does rely on two different standards when one would cover it.

Not saying I haven't used ARIA described-by in production, just that I think that use case could be simplified. In terms of *html validation* that use case is questionable as it's ARIA not HTML.

(In reply to comment #5)
> Yes I think multiple labels should be valid (I'm sure I recall seeing that
> documented as valid prior to html5). 
> 
> Have seen that exact use case actually - additional/long descriptions,
> hints, error states etc on form inputs with an existing shorter label.

yeah its not clear in html5, but its still valid to do:

see http://blog.paciellogroup.com/2012/05/notes-on-using-multiple-labels-for-a-control-using-the-label-element/

(In reply to comment #6)
> Sorry should have said multiple *correctly-associated* labels :)
> 
> I'd prefer to use multiple labels with for="foo" than two different methods
> of association; that is, that use case does rely on two different standards
> when one would cover it.
> 
> Not saying I haven't used ARIA described-by in production, just that I think
> that use case could be simplified. In terms of *html validation* that use
> case is questionable as it's ARIA not HTML.

I have pinged mike smith who works on the w3c validator to get his take on it.

ARIA validation would definitely be useful :) I'd happily see ARIA rolled into the validator, personally. Raw HTML5 doesn't cut it for most modern sites and apps.

(In reply to comment #9)
> ARIA validation would definitely be useful :) I'd happily see ARIA rolled
> into the validator, personally. Raw HTML5 doesn't cut it for most modern
> sites and apps.

ARIA validation is already in the validator: http://validator.w3.org/nu/

it validates the rules as per http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics & http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics

Oops, guess I haven't been paying attention then ;) OK, with that in mind the code example with secondary label does make sense and could be considered either conforming, or potentially a warning. 

As a pattern I'd also want to consider the case where that example had a third bit of information to deal with, eg. explaining an error/invalid state. Would you add to the description? Use an alert or status?

From an author's point of view I do think I should mention I've rarely used the "wrap label around control" pattern. It just isn't as flexible for rendering and layout as separate elements linked with for.

(In reply to comment #11)
> Oops, guess I haven't been paying attention then ;) OK, with that in mind
> the code example with secondary label does make sense and could be
> considered either conforming, or potentially a warning. 
> 
> As a pattern I'd also want to consider the case where that example had a
> third bit of information to deal with, eg. explaining an error/invalid
> state. Would you add to the description? Use an alert or status?
> 
> From an author's point of view I do think I should mention I've rarely used
> the "wrap label around control" pattern. It just isn't as flexible for
> rendering and layout as separate elements linked with for.

do you mean something like this?

<label id="label1" for="f3">label text </label> 
<input type="text" id="f3" aria-labelledby="label1 label2 label3"> 
<p>other content</p> 
<label id="label2">more label text</label>
<p>other content</p> 
<label id="label3">even more label text</label>

note the flexibility of this technique is that that the labels can be associated with multiple controls:


<label id="label1" for="f3">label text </label> 
<input type="text" id="f3" aria-labelledby="label1 label3"> 

<label id="label2" for="f4">label text </label> 
<input type="text" id="f4" aria-labelledby="label2 label3"> 
<p>other content</p> 

<!-- this label labels 2 controls -->

<label id="label3">more label text</label>

(In reply to comment #3)
> I agree that a label which does not label a control (either by wrapping or
> explicit association) should be an error.
> 
> Use of the element would imply its purpose is to label something - that is
> we can infer some author intent - so if it does not in fact do so I think
> it's fair to say it's an author error. 
> 
> To think of it another way, if that slipped through in my code I'd want to
> get an error :)

I agree with Ben here. I think if somebody has a document that has a <label> element without either a "for" attribute or any "labelable elements" as descendants, there's a high probability that it's not intentional but instead is an authoring oversight/mistake that they'd like to be alerted about. So I think it would be useful for the validator to emit a message here, even if it's just a warning.

(In reply to comment #12)
> <label id="label1" for="f3">label text </label> 
> <input type="text" id="f3" aria-labelledby="label1 label2 label3"> 
> <p>other content</p> 
> <label id="label2">more label text</label>
> <p>other content</p> 
> <label id="label3">even more label text</label>

So that example would not be valid if we were to change the spec to say a <label> element must have either a "for" attribute or a "labelable elementa" as a descendant.

I recognize that the "aria-labelledby" attribute on the <input> element in the example achieves a similar purpose, but I'm personally reluctant to start making any core document-conformance rules change depending on particular ARIA attributes, and I think it'd not unreasonable to consider it a layering violation.

(In reply to comment #14)
> (In reply to comment #12)
> > <label id="label1" for="f3">label text </label> 
> > <input type="text" id="f3" aria-labelledby="label1 label2 label3"> 
> > <p>other content</p> 
> > <label id="label2">more label text</label>
> > <p>other content</p> 
> > <label id="label3">even more label text</label>
> 
> So that example would not be valid if we were to change the spec to say a
> <label> element must have either a "for" attribute or a "labelable elementa"
> as a descendant.
> 
> I recognize that the "aria-labelledby" attribute on the <input> element in
> the example achieves a similar purpose, but I'm personally reluctant to
> start making any core document-conformance rules change depending on
> particular ARIA attributes, and I think it'd not unreasonable to consider it
> a layering violation.

can you provide more detail on the reasons for you personal reluctance and what the term 'layering violation' means a pointer to where it is defined would be especially helpful. What are the negative effects of allowing document conformance rules dependent on the presence of particular aria attributes?

(In reply to comment #14)
> (In reply to comment #12)
> > <label id="label1" for="f3">label text </label> 
> > <input type="text" id="f3" aria-labelledby="label1 label2 label3"> 
> > <p>other content</p> 
> > <label id="label2">more label text</label>
> > <p>other content</p> 
> > <label id="label3">even more label text</label>
> 
> So that example would not be valid if we were to change the spec to say a
> <label> element must have either a "for" attribute or a "labelable elementa"
> as a descendant.
> 
> I recognize that the "aria-labelledby" attribute on the <input> element in
> the example achieves a similar purpose, but I'm personally reluctant to
> start making any core document-conformance rules change depending on
> particular ARIA attributes, and I think it'd not unreasonable to consider it
> a layering violation.

I have to agree with making the first statement.

If you disregard ARIA for a second and look at the purpose of each of the labels, then the author's intention would be to 'link' the labels to another element, right?

This implies an association between each of the labels and its 'target'. I think a "for" attribute should be required in such a case, even if there's an ARIA role that already links them.

As a side-note: I think label wrapping is fairly common when checkboxes and radio buttons are involved. I've seen the pattern before and use it myself as well in most cases, as it's a nice way to render the label inline with a control.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: rejected
Change Description: no spec change
Rationale: agreed with commenters