Unnecessary for/id attributes in Basic HTML and HTML5

Describe your problem and how to reproduce it:

Form challenges in the Basic HTML and HTML5 course suggest using for attributes on form labels:

It is considered best practice to set a for attribute on the label element, with a value that matches the value of the id attribute of the input element.

However, this is only true when inputs are not nested within labels. When using nesting, this relationship is created implicitly - see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label

Therefore, the following example in the link below:

<label for="indoor"> 
  <input id="indoor" type="radio" name="indoor-outdoor">Indoor 
</label>

should either be removed in favour of keeping only the first example (which features a nested label without explicit association), or replaced with a non-nested version (often preferred in real-world scenarios due to more styling control):

<input id="indoor" type="radio" name="indoor-outdoor">
<label for="indoor">Indoor</label>

Why I feel this is important:

For a beginner learning HTML, explicit relationships using attributes introduce additional cognitive load and are unnecessary due to the implicit relationship created by nesting. They could also create confusion when the name and value attributes are introduced later - in the context of forms, name or value often share the same value with id, so they could be mixed up easily by a beginner.

Additional notes:

I have tested with VoiceOver on macOS and NVDA on Windows, across Chrome and Firefox (both systems) and Safari (on macOS), and confirmed that input labels are read aloud correctly when using implicit association.

Add a Link to the page with the problem:

https://www.freecodecamp.org/learn/responsive-web-design/basic-html-and-html5/create-a-set-of-radio-buttons (and subsequent form-based challenges)

Tell us about your browser and operating system:

Screen reader support for nested labels tested across the following browsers:

Browser Name: Google Chrome
Browser Version: 89.0.4389.90 (Official Build) (arm64)
Operating System: macOS Big Sur 11.3 Beta (20E5217a)

Browser Name: Firefox
Browser Version: 87.0 (64-bit)
Operating System: macOS Big Sur 11.3 Beta (20E5217a)

Browser Name: Safari
Browser Version: 14.1 (16611.1.21.1.12)
Operating System: macOS Big Sur 11.3 Beta (20E5217a)

Browser Name: Google Chrome
Browser Version: 89.0.4389.90 (Official Build) (64-bit)
Operating System: Windows 10 Pro 20H2 19042.906

Browser Name: Firefox
Browser Version: 87.0 (64-bit)
Operating System: Windows 10 Pro 20H2 19042.906

If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):

See code examples above

[RandellDawson]

I agree that the example shown above by @hassaanp should replace the existing example, but I also don’t think it would hurt to put the existing example after it. There is nothing that says you can not do what our example shows (that I am aware of).

[ShaunSHamilton]

I could go either way - leave as is, or change to what has been mentioned. 👍

I do want to point out: https://html.spec.whatwg.org/multipage/forms.html#the-label-element

If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element’s labeled control.

I can imagine a case where there is more than one labelable element descendant within a label element (perhaps, not semantically correct), and the for attribute would be required, if the desired associative element is not first.

Probably just me (maybe, even freeCodeCamp’s fault), but I always give my labels an associated for attribute.