Implicit, explicit or both for form labels?

Accessibility
1

Concerning: User Agent and Assistive Technology Support Notes:

The HTML and XHTML specifications allow both implicit and explicit labels. However, some assistive technologies do not correctly handle implicit labels (for example, <label>First name <input type=“text” name=“firstname”></label>).

Is that still true or is it outdated information?

I’ve seen implicit defined as both the label and input being contained in the same element but I always thought, as stated above, an implicit label surrounds the input like this (without the “for” attribute ):

<label>First Name: <input type="text" id="firstName" /></label>

… and explicit labels use the “for” attribute with the label and input being separated like this:

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

In the past I’ve used a mixture of both like this:

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

I was told that this wasn’t acceptable as it was either implicit or explicit but not both. Is this a safe option or does it have the same issues as the implicit labels mentioned in the quote?

2

I’ve always gone for the second option (explicit only), because it will always be possible to do that, no matter what your layout or structure. Implicit association of labels is fine but there are times when you need the label in a separate contained to the input and so then you can’t use implicit association. If you use explicit only then that’s one less thing to worry about when setting up the <form>. Much easier to be in the habit of doing it automatically in every situation.

I’ve never tried to implicitly and explicitly associate a label. What does the W3 Validator say about it? I guess one problem could be that you “for” the label to a different input to the one you’ve implicitly associated, which would be a tricky one for user agents to resolve.

3

It passes. I have not tried it using a screen reader though so I don’t know if it overcomes the issue in the OP.

4

Interesting scenario Mark but the third version looks rather bizarre to say the least. I can understand how it may confuse matters in a user agent as to which takes precedence, you’d assume ‘for’ wins as it would theoretically hold more weight.

I think a lot of people get over worried about screen reader failings/bugs as the web author you know that the ‘for’ version is more powerful of the two. The onus is supposed to be on the AT software vendor for making the reader work properly; if you have followed the correct semantics and not really the web author. So I’d probably choose one or the other to stop any potential ambiguity.

5

I had a internet glitch than knocked-out the [edit] button but the last paragraph was supposed to imply it’s not really the web author’s fault if you follow the correct best practice semantics but the AT still has issues.

6

The most recent info that I know of is from Steve Faulkner’s blog in July 2011: Link. See the link to his test results about half-way through the article.

7

I agree but I may as well not make things purposely harder for someone just because I’ve always done things that way. :slight_smile:

That’s the information I was looking for. :slight_smile:

8

Yes, you have to do your best basically if possible where “real world” software bugs make it more of a challenge for the web author. So long as it doesn’t hinder other things too greatly, and it looks like my hunch was correct.

9

The implicit version may be valid structurally but it is garbage semantically as the input field is not really a part of the label.

Since an id comes in handy on each input field in order to attach JavaScript validation it isn’t making the HTML any simpler to read or much shorter if you use the implicit version so you may as well use the semantic version instead.

10

Given that a lack of explicit is INVALID MARKUP in HTML 4.01 strict or XHTML 1.0 Strict… the answer should be self evident. Only when sleazing out HTML 3.2 and slapping a tranny doctype on it is omitting the ‘for’ attribute valid.

Not sure what 5 says about it, but given it basically flushes all the progress of strict down the toilet throwing us back to 1998 coding standards…

11

[ot]

Remember, dude, it’s all about “paving the cowpats”, or something like that.[/ot]

12

Mike’s post is older than Steve Faulkner’s, but this is what’s kept me often from wrapping implicit (or both):

It wasn’t just Window-Eyes (which seems to be falling further and further behind current specs, having all sorts of trouble with HTML5 and ARIA), but also this strange, intermittant Mac thing. “Intermittant” being a keyword: nobody could tell what triggered itt or why, so it was a scary-don’t-do (this was sighted Mac users).
I don’t tend to worry much about what NVDA does or doesn’t do, cause those 2 guys are usually on the ball, and their reader is free so pretty easy to update (and open-source). Maybe for that reason, NVDA is like the most on-top-of-everything reader with regards to HTML5 and ARIA. Orca has the possibility to also be on the ball for the same reasons, but it seems it’s a constant fight with Gnome bugs and Mozilla/Gecko and webkit bugs. :confused:

So I worry more about the large commercial readers that people simply cannot afford to update often and also the companies are just slower in development: JAWS, Window-Eyes and VoiceOver.

Jason Kiss’ tests also include the System Access toGo reader, which I know pretty much nothing about. http://www.accessibleculture.org/ excellent resource and also many tests, for those curious about how various ARIA and HTML5 thingies are going. Invaluable really, especially coupled with Steve’s tests.

13

I suppose it would be self evident if the validator threw an error in either case.

14

Ah, nice. Good information.

Good point. :slight_smile:

15

It’s not strictly in all cases invalid markup to wrap LABEL around a form control without a ‘for’ attribute in Strict. Though it might be considered best practice to use such an attribute. Since the ‘for’ explicitly associates the label being defined with another control.

16

Association is implied by containment.

17

No it isn’t. Containment implies that it is part of the label - it doesn’t identify what is being labelled. Only the for attribute attaches the label to whatever is being labelled - which shouldn’t really be a part of the label itself as that makes it recursive.

Anyway not all of the standard is actually checked by the validator. Just because something passes validation doesn’t mean it is valid. There are some parts of the standard that were not implemented within the validator - eg. that an input field must be inside a form but NOT directly inside a form.

18

Last I knew it did… one moment… did they just recently change that in the validator or something because I KNOW that LABEL without FOR used to throw an error in strict… It’s the entire reason I discovered there was a FOR attribute in the first place!

Though is it just me, or are half the warnings and a quarter the errors now just missing from the W3C validator or something? Like I’m not seeing it constantly kvetching about “you set a background color and not a foreground one on this element” anymore.

19

It’s been like that for years you could have the following and it would pass, i.e. we have a block wrapping the LABEL.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
   <title>A Form lacking (no fieldset)</title>
</head>
  <body>
   <form method="post" action="example.php">
    <div><label>username: <input type="text" name="message" /></label>
   <input type="submit" value="Submit" name="submit" /></div>
   </form>
  </body>
</html>

The CSS Validators have different settings regarding warnings and errors and they do tend to change those quite a bit.

20

<label>username: <input type=“text” name=“message” /></label>

doesn’t identify which field that ‘username: <input type=“text” name=“message” />’ is the label for.

Also no one uses Netscape 4 any more so space-slash-greaterthan is no longer a relevant construct to use and the space on the front that was only necessary for Netscape 4 ought to be dropped.