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:

The interactive element is not associated with the form control through implicit means or by an aria-describedby mechanism.
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: https://github.com/mdn/content/commit/9c09b183a5ce844a75c2f22e909d03f71ca329fc * Document last modified: 2024-07-26T02:20:41.000Z

extra808 commented 19 hours ago

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.
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.
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.
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 commented 18 hours ago

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 commented 2 hours ago

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."

mdn / content

Subpar accessibility recommendation #36068

MDN URL