|'Best practice for <label>|
Standalone - or wrap <input />?
| 5:00 am on Nov 20, 2009 (gmt 0)|
A recent thread in another forum had a code sample that wrapped the <label> around the input:
<label for="sample" id="sample">Label
<input type="text" id="text" value="Initial value." />
However, I have been reading conflicting opinions - that the <label> should contain only itself; and that the label should wrap <form> element with which it is associated. Both validate. W3C shows examples of both, but is, as ever, woeful with examplification.
I have primarily always used the former, but markup for either easy to find - what is best practice for Accessibility - within reason?
456 Berea St. [456bereastreet.com] A couple of years old, but one of the better resources at addressing implicit and explicit association as well as the question of when wrapping (implicit) might be preferable and that using both techniques has its place.
I do my best to accommodate Accessibility, up to a point. I do think that there is a responsibility of developers of screen-readers, et cetera, to do a lot better job of with their software. I don't feel responsible for accommodating users of fractional percentages, but do try to do my best for the most; in part for personal reasons; in part because it makes all of my markup and awareness of considertions/options stronger.
| 6:40 am on Nov 20, 2009 (gmt 0)|
Hmmm... I've always defaulted to the adjacent/explicit method, though more through ignorance than anything else. Until you pointed it out, I never noticed that the W3C spec (both HTML 4.01 and WCAG) show it used both ways.
For screen readers, WebAIM recommends the label be adjacent to the form item it labels and that it be associated via the for attribute. Whatever that's worth.
Have you tried both versions in screen readers?
| 6:49 am on Nov 20, 2009 (gmt 0)|
My eyebrows raised when I saw what I presume is the same thread...
I can't remember where or when I first used labels... and I guess that - as my files always validate - I've never given it much thought... even though I do try to think pro-actively about accessibility...
From the Berea St article:
|This could be very useful for displaying hints and error messages since it would let you separate those messages in the markup for much easier positioning and styling. |
Hmmm... Colour me ambivalent
|Unfortunately my limited screen reader testing (JAWS 8.0 and VoiceOver) of multiple labels suggests that screen readers ignore them. |
| 6:54 pm on Nov 20, 2009 (gmt 0)|
Well, common sense dictates that anything inside a label should be just that, a label, right? So semantically, a label should only contain a label.
Second, it's also an accessibility tool. Code up a test:
<p><label for="test">Test</label> <input type="text" name="test" id="test"></p>
<p><label for="test2">Test 2</label> <input type="text" name="test2" id="test2"></p>
<p><label for="test3">Test 3</label> <input type="text" name="test3" id="test3"></p>
On load - nothing new. But mouse over the text "Test 2" and click.
What happens? It tabs the cursor to the field "test2", and does so for any of the other labels.
This still works if the label surrounds the controls, but like tables for layout, <br><br> for space when you don't care about the semantics of <p> or how to style it for the effect you want, and other "perversions" of elements, it's not how the element was intended to be used. Also like those examples, "if it works it works," and if presentation is your only directive, it doesn't matter (but should . . . )
It's also a great tool for screen readers when correctly used.