Victorino Machava
Victorino Machava

Reputation: 648

Should a label element have both a for attribute and a nested input element?

I know we can either use

Explicit Labeling:

<label for="myinput">My Text</label>
<input type="text" id="myinput">

or

Implicit Labeling:

<label>My Text
   <input type="text">
</label>

What about using both:

<label for="myinput">My Text
   <input type="text" id="myinput" />
</label>

You can read here the following recommendation

To fully cover 100% of assistive devices, you're encouraged to validate for both nesting and id.

What is the recommended way?

Upvotes: 5

Views: 5316

Answers (2)

GrahamTheDev
GrahamTheDev

Reputation: 24935

Short Answer

Use either not both.

  • use for="" if you want maximum compatibility
  • use label wrapping if you want maintainability and cleaner code.

Using both is overkill and increases code complexity.

Using either option is WCAG compliant.

Longer Answer

After a bit of digging I came across this interesting test.

In short, screen readers all behave nicely with both versions but Dragon Naturally Speaking still does not behave well with wrapped labels.

Now I have never seen anything that says using both is actually an accessibility issue, however if you are adding for="" you lose the main benefit of using wrapped labels anyway.

side note - Interestingly we changed our internal guidance earlier in the year to use wrapped inputs as screen reader support was good across the board for our chosen browser / screen reader support combos (after ditching IE8 support, if you need to support IE8 then you need to still use for="" and not wrapped inputs).

I am now going to reverse that decision and will be going back to good old for="" associated labels while we investigate the Dragon issue.

Dragon Naturally Speaking is widely used as Assistive Technology (AT), even though it isn't officially AT.

Does it really matter

I advise people on accessibility, I have to be whiter than white, purer than pure (practice what I preach).

In reality if you want to use wrapped labels because they are easier, then use them, support is 100% of modern browsers (IE9 and above) with screen readers.

If you want to use for="" still then that has the best support. This would be my official recommendation, but I also believe that technology does need to move on and the problem should be addressed by Dragon Naturally Speaking, their excuse of "not being assistive technology" is not valid as they are still covered under the Equality Act 2010, ADA etc. (insert your country specific Disability Equality laws here)

Using both is just overkill and removes most of the benefits of wrapped labels anyway and I don't see the point in using both (other than perhaps the fact that in the future you could then remove the for="" on a wrapped label if Dragon fixes this issue).

Final note

The documentation for this test you linked says in big writing [Deprecated] and links through to this documentation for a replacement test.

I could not see the justification for why they removed the requirement to use both (as I have still not seen evidence that using both causes issues as I stated earlier) but at least this is inline with my recommendation.

Upvotes: 6

Impirator
Impirator

Reputation: 1442

Either explicit labeling or implicit labeling is sufficient (W3C spec). According to MDN, nesting a form element and using the for attribute is fine as long as the nested element has the id which matches the for, but it is unnecessary. I take the quote in your post to mean that you should have two separate test cases for explicit and implicit usages, rather than one case with both a nested form element and a for attribute.

As far as what's "recommended," I would say that depends on your specific scenario. Personally, I always try to nest my form element in a <label> because I don't have to bother with for and id at all that way, and the association between the two is very clear from the code. Whenever the <label> can't be the form element's parent, then I reach for for.

Upvotes: 1

Related Questions