This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The label element has some restrictions in the fact that it can contain no form controls but its labeled control, and it can't contain other label elements. However, one more restriction should apply: it shouldn't be allowed to contain any <a> element with a @href attribute, because on some user agents (I tested it on Chrome, latest version as of now) clicking on link prevents the control state change behavior, even if the link points to a different browsing context (e.g. iframe, popup, new tab). Or probably it shouldn't contain any interactive element, for the same reason: conflict arises between events. http://www.w3.org/TR/html5/forms.html#the-label-element
That would be a harmful limitation. Checkbox itself as a form control is clickable anyway while _text_ inside link inside the form-control's label may make sense in terms of _accessibility_. For example: <ul> <li><label> <input type="checkbox" name="music" /> <a href="/music/">Music</a> </label></li> <li><label> <input type="checkbox" name="photo" /> <a href="/photo/">Photo</a> </label></li> <li><label> <input type="checkbox" name="sport" /> <a href="/sport/">Sport</a> </label></li> </ul> <input type="submit" value="Apply filters" /> In the example, each link points directly to its corresponding category page in just one click (without need for two redundant clicks: 1. single checkbox; 2. submit button) while it's still possible to select multiple categories using corresponding checkboxes _when needed_ while text of each link is useful as an accessible label text regardless of whether the link itself is clickable.
Probably I didn't explain myself correctly. Your example is quite good and I wanted to build something similar. But the problem is that clicking on link actually prevents the change of state (checked/unchecked) of the control itself. So, allowing authors to use <label><a href="url">label text</a></label> is pointless, as controls remain in their original state. The link itself IS clickable. Which is the only action you achieve. You would achieve more correct results, even at the cost of duplicating text inside the page, if you keep the navigation and the check controls separated (e.g. a navigation column and a newsletter subscription form).
(In reply to comment #2) > Your example is quite good and I wanted to build something similar. But the > problem is that clicking on link actually prevents the change of state > (checked/unchecked) of the control itself. This is not a problem since clicking the link makes the corresponding page to load which is what user intended to do. It does not matter at all if the checkbox on the previous page has remained unchecked. > You would achieve more > correct results, even at the cost of duplicating text inside the page, if > you keep the navigation and the check controls separated (e.g. a navigation > column and a newsletter subscription form). Results are already correct. There is no a newsletter subscription form in my example. This is a form to view events of some type or types on a real-world website I've developed some time ago. If a single category is what user want, he just clicks the corresponding link while, to filter events by multiple categories, user may use corresponding checkboxes and submit button. Duplicating things (especially just for the purpose of pure theory) is evil almost always.
(In reply to Marat Tanalin | tanalin.com from comment #3) I understand that duplicating things can be quite useless (not "evil", just what damages the user experience is evil actually). Anyway, you will have to notify the users of your website that clicking on the names with the purpose of checking the checkboxes (which is something users do sometimes) has not that effect (unless links are graphically evident. A sidenote: were the <label><a href="url">label text</a></label> not allowed, this is how I would solve that markup issue (which is not an issue in your opinion): <dl> <dt> <label><input type="checkbox" name="music" /> Music</label> </dt> <dd><a href="/music/">Check the page</a></dd> <dt> <label><input type="checkbox" name="photo" /> Photo</label> </dt> <dd><a href="/photo/">Check the page</a> <dt> <label><input type="checkbox" name="sport" /> Sport</label> </dt> <dd><a href="/sport/">Check the page</a></dd> </dl> <input type="submit" value="Apply filters" /> Which is of course my personal interpretation and I don't want by any mean suggest that it's better or worse than anybody else's. Just notice that label, besides being an accessibility feature, is also an interactive control and people tend to use it, especially on mobile devices where touching a whole word is more comfortable than touching the single control. Anyway, I also expect what will be said from authors.
HTML5.1 Bugzilla Bug Triage: Works for me If I read the conclusion right, then we have some justification for allowing a[href] in <label>, even if the effect is not perhaps what was intended by the author. If I got that wrong, please file an issue as noted below and we'll start the dialog again. If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!