Forms: Make single Checkbox row fully clickable (FORMS-684)

[alinclamba]

Fixes #41522
Linear: FORMS-684

On a Jetpack Form, clicking the empty space between a single Checkbox input and its label text did nothing. Only the input itself and the label text were clickable. This narrows the click target and is inconsistent with how the Radio and Multi-Choice fields already behave.

Proposed changes

• In projects/packages/forms/src/contact-form/class-contact-form-field.php, swap the <input> and <label> open-tag lines inside render_checkbox_field() so the <label> wraps the <input> instead of being its sibling.
• No CSS changes. No editor-side changes. No attribute changes.

Root cause

render_checkbox_field() emits the <input> and <label> as siblings inside a wrapper <div>:

<div class="contact-form__checkbox-wrap">
  <input id="…" type="checkbox" … />
  <label for="…">…</label>
</div>

The wrapper is a <div>, not a <label>, so clicks in the gap between the input and the label text don't toggle the input. Browsers only forward clicks to a checkbox via the input itself or via a <label> that either wraps it or is associated with it through a labelable click target — the gap belongs to the <div> and isn't either.

Fix

Move the <label> open tag above the <input> so the label wraps the input:

<div class="contact-form__checkbox-wrap">
  <label for="…">
    <input id="…" type="checkbox" … />
    …
  </label>
</div>

This matches the convention already used by:

• the consent field (render_consent_field)
• the multi-checkbox optionsdata rendering path (refactored as a side effect of FORMS-131, PR Forms: use entire button area for selecting multi-select options #46263, merged Dec 2025)
• the radio optionsdata rendering path (refactored as a side effect of PR Forms: Add 'Other' option support to radio fields #46461)

The original GitHub issue #41522 reported this bug for single Checkbox, Radio, and Multi-Choice. Radio and Multi-Choice were fixed incidentally by the two PRs above; single Checkbox has its own dedicated render path that wasn't touched. This PR addresses only that remaining path.

What is intentionally not changed

• for= attribute on the label is kept. It's now redundant for click association (the wrapping handles it) but keeping it costs nothing and avoids breaking any external tool that might key off it.
• id= attribute on the input is kept. It's reused by get_error_div( $id, 'checkbox' ) so it has to stay.
• The outer <div class="contact-form__checkbox-wrap"> wrapper is kept. It diverges from render_consent_field()'s pattern (which has no equivalent wrapper), but removing it would be a separate structural change with its own theme-compatibility risk (the class is public-facing CSS, possibly targeted by external theme stylesheets) and is out of scope for this PR.
• Legacy radio path (around line 1396, reachable only via the deprecated shortcode syntax) is not touched.
• No CSS changes. The existing .contact-form__checkbox-wrap { display: inline-flex; align-items: baseline } rule continues to apply at the wrapper level. Visual parity with the previous rendering was confirmed manually on Twenty Twenty-Five with no observed regressions.
• No editor-side changes. The editor preview is rendered by a different code path (the inner jetpack/option block) and the bug only ever manifested on the published frontend.

Visual evidence

Before (no fix), recorded on a sandbox without the FORMS-684 patch:

After (with fix), recorded on impossibly-literary.jurassic.ninja with the build deployed:

Testing instructions

1. Apply the patch to a Jurassic Ninja site (or any site with Jetpack 15.8 / trunk). Create a page with a Jetpack Form block containing a Checkbox field. Publish.
2. On the frontend, click in the empty space between the checkbox input and the label text. The checkbox should toggle.
3. Click on the input itself. Should still toggle.
4. Click on the label text. Should still toggle.
5. Mark the Checkbox required in the editor. Submit the form without checking it. The error message should still appear, and the required indicator span should still render inside the label.
6. Add a Radio field and a Multi-Choice (multi-checkbox) field to the same form to confirm those keep working as before.
7. Try at least two themes (e.g. Twenty Twenty-Five and Twenty Twenty-Four).

Does this pull request change what data or activity we track or use?

No. No data, schema, or API changes.

Notes

• No editor-side changes. The editor preview (field-checkbox/edit.js + the inner jetpack/option block) renders the checkbox via <RichText> and a non-interactive <input> in a different DOM shape; this PR only affects the published frontend.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack), and enable the fix/forms-checkbox-click-area branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fix/forms-checkbox-click-area

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report · JS report

[alinclamba]

Ran /jetpack-review-pr locally before flipping to ready. Verdict: LGTM, no issues.

[alinclamba]

I noticed @enejb is AFK so kindly asking @talldan to review this if possible.