Move checkbox input outside of the wrapping `label` element.

[kkmuffme]

[Edited to change the intent of the ticket. Original intent below.]

<label for="dashboard_right_now-hide">
	<input class="hide-postbox-tog" name="dashboard_right_now-hide" type="checkbox" id="dashboard_right_now-hide" value="dashboard_right_now"/>At a Glance
</label>

The for= is redundant and can be removed, since the input is wrapped in the label
There are a couple other ones there with the same issue

Trac ticket: https://core.trac.wordpress.org/ticket/62548

I’m not entirely sure if it’s considered best practice to omit the for attribute from a <label> tag when it wraps an <input> element. While the association between the label and input is implicit in this case, I’d appreciate confirmation on whether this approach aligns with accessibility and coding standards.

If this is acceptable, you can proceed with this PR fix. Thank you!

[sabernhardt]

As @afercia noted in ticket:47141#comment:1, the ​accessibility coding standards in 2018 said that the labels should not combine both methods.

Existing code uses a mixture of explicitly and implicitly labeled fields, but all new code must use an explicitly associated <label> element (using for/id attributes and not wrapping the form control).

[34991] removed the for attribute in the implicitly associated hide-column-tog checkbox labels with list tables, but other screen options still have the for attribute:

• the hide-postbox-tog checkboxes on the Dashboard
• wp_welcome_panel-hide on the Dashboard
• editor-expand-toggle in the Classic Editor

Removing the for attributes from these implicitly labeled checkboxes would be simple. If switching to explicit association, the input/label pairs should still have a wrapper span to make sure they stay together when they appear on multiple lines.

[joedolson]

If we change this, it should be to remove the wrapping label, so that the only label relationship is the explicit one. This is a relatively low priority change, but in most cases not complex. However, removing wrapping label elements can have significant impact on styling (e.g., if there's a flex or grid context involving that label), so they need to be handled carefully in individual cases.

But in no circumstances should we elect to remove the for attributes so that we only use implicit labeling.

[joedolson]

This is referring to the Screen elements form in screen options. There's no impact on styles by moving the input out of the wrapping label, so we might as well do that.

[benazeer]

Thank you for pointing that out.

Since there’s no impact on styles by moving the input out of the wrapping label, it makes sense to proceed with this change. This adjustment ensures better markup semantics without affecting the visual output.

I have updated this in recent commit in this PR ​https://github.com/WordPress/wordpress-develop/pull/7887

Let me know if there's anything else that needs attention.

[sabernhardt]

when the checkbox is before the label, without a wrapping element, the label can appear on the next line

[sabernhardt]

There's no impact on styles

Yes, moving the checkboxes outside of (and before) their labels would have at least two issues just with Core styles, and plugins can make the situation worse.

1. The checkbox and label text need some kind of wrapping element to keep them together across multiple rows (comment:3).
2. The checkboxes have a 6-pixel right margin that would become unclickable if the input is outside the label.
3. ​Plugin styles and scripts target the labels—even to hide or remove them—and some styles target inputs inside labels.

The first two issues theoretically could be fixed by adding a wrapper span and by reassigning the 6 pixels to the left padding of the label.

.metabox-prefs .new-wrapper-span-class-name {
	display: inline-block;
}
.metabox-prefs .new-wrapper-span-class-name input {
	margin-right: 0;
}
.metabox-prefs .new-wrapper-span-class-name input + label {
	padding-left: 6px;
}

Looking at a few ​plugins from the search results, I did not find a specific problem with explicit labels. Plugins that include ​WPAlchemy might not use its .remove() script to remove screen options. The Themify plugins would hide the label (yet show the checkbox) if no options are available, but I had option fields with both Themify Popup and Themify Portfolio Post when adding a new item.

Ultimately, however, I do not want to force any extenders to update their code because of a 'trivial' and 'relatively low priority' change. The admin redesign should avoid implicit labels, and I would prefer to wait until then to worry about it.

[joedolson]

Given the potential impacts and the relatively minor concerns, and the fact that voice command users are the primary group effected by this change and they do have numerous other mechanisms for handling form controls, I'm going to go ahead and close this issue. However, we should definitely make sure that this is not done the same away in a future admin redesign.