Subpar accessibility recommendation

[LukeLeber]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label

What specific section or headline is this issue about?

#Interactive content

What information was incorrect, unhelpful, or incomplete?

The recommended pattern to add interactive elements such as anchors or buttons after the label would mean that:

1. The interactive element is not associated with the form control through implicit means or by an aria-describedby mechanism.
2. The user likely already interacted with the proceeding form control before knowing there was more content critical to the context following.

The recommendation seems to be worse than the pattern to avoid.

What did you expect to see?

Wouldn't it be better, given the current state of assistive tech tooling and web standards to include visually hidden context inside the label that indicates to users that an interactive element exists in the label versus the recommended alternative?

Do you have any supporting links, references, or citations?

Common sense as an avid keyboard user 😁.

Do you have anything more you want to share?

No response

MDN metadata

Page report details

• Folder: en-us/web/html/element/label
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/html/element/label/index.md
• Last commit: 9c09b18
• Document last modified: 2024-07-26T02:20:41.000Z

[extra808]

1. A link inside a label is not programmatically associated with the label or the input. Visually, there's an association by the link text also being part of the input's label but a link after the label+input is also associated by sequence and visual proximity. Giving the link an id, regardless of where it is, and pointing an aria-describedby on the input at it could be clarifying but A) I think proximity and sequence is sufficient and B) not all screen readers are configured to automatically read descriptions.
2. In both versions a sighted user likely sees the link to the Terms and Conditions page at the same time as the checkbox and can choose to read them first (or more likely, not). A user who doesn't see the link first can go back and change their use of the checkbox once they have.
3. In the "Don't do" version, when the input's name is read by a screen reader, the existence of the link will not be conveyed; the screen reader user will likely encounter it when they continue navigating so the experience is equivalent to the "Do" version.
4. The advice to not nest interactive elements is primarily for cursor/touch users, not keyboard users. In the "Don't do" version an attempt to click the link could accidentally change the checkbox's state instead. This could be clarified by changing

Doing so makes it difficult for people to activate the form input associated with the label

to

Doing so makes it difficult for people using a pointer to activate the form input associated with the label.

I agree that a Terms and Conditions link should be in the DOM prior to the input asking people to agree to it. This is also one of the rare cases where opening a link in a new tab is preferable, to avoid people losing unsaved form input (if the checkbox was the only input, that wouldn't be a problem).

<p>
  <a href="terms-and-conditions.html" target="_blank">Read our Terms and Conditions</a>
</p>
<label for="tac">
  <input id="tac" type="checkbox" name="terms-and-conditions" />
  I agree to the Terms and Conditions
</label>

[LukeLeber]

Would it perhaps be more semantically correct to wrap the link to read the ToS and agreement checkbox in a fieldset?

<fieldset>
  <legend>Please review the terms of service and agree to them.</legend>
  <p>
    <a href="terms-and-conditions.html" target="_blank">Read our Terms and Conditions (opens in a new tab)</a>
  </p>
  <label for="tac">
    <input id="tac" type="checkbox" name="terms-and-conditions" />
  I agree to the Terms and Conditions
  </label>
</fieldset>

The fieldset effectively adds semantic linkage, not only proximity, to the expected operation.

[extra808]

As the page says,

If a form, or a section of a form needs a title, use the <legend> element placed within a <fieldset>.

I don't think the link and input need a title, the link text and input labels are clear enough.

Also, I assume the examples used in MDN articles are kept intentionally brief; a <fieldset> is unrelated to the topic at hand, which is "don't nest interactive elements."

[Josh-Cena]

This seems very related to #33283 and should be fixed together. @extra808 so in your opinion should anything be changed? @estelle could provide opinions too.

[extra808]

#33283 makes a good point about the current text potentially mischaracterizing the relationship between label and labelable elements, like button.

Here's are a couple of attempts at combining the two issues:

Don't place additional interactive elements, such as {{HTMLElement("a", "anchors")}} or {{HTMLElement("button", "buttons")}}, inside a `label`. Doing so makes it difficult for people using a pointer to activate the form input associated with the `label`.

Don't place additional interactive elements, such as {{HTMLElement("a", "anchors")}} or {{HTMLElement("button", "buttons")}}, inside a `label`. Doing so overlaps the hit areas of the interactive elements and the `label`, making it difficult for people using touch-screen devices or who have difficulty precisely controlling a cursor to activate right element.

And then for the good example, at minimum I'd move the link to be before the checkbox instead of after.

<p>
  <a href="terms-and-conditions.html" target="_blank">Read our Terms and Conditions (opens in a new tab)</a>
</p>
<label for="tac">
  <input id="tac" type="checkbox" name="terms-and-conditions" />
  I agree to the Terms and Conditions
</label>

While the target="_blank" and "(opens in a new tab)" on the link are often a good practice for links within forms, not every form needs them. If MDN has a general practice of keeping examples as minimal and on-topic as possible, they could be omitted.