Forms: Fix checkbox styling with filter invert and correct border color

[CGastrell]

This is an alternative to #46129 getting to the same "contrast" goal but with an inverted approach.

Proposed changes:

• Replace background-color: currentColor with filter: invert(1) for checked checkbox state
• Split the border rule declaration for the checkbox checkmark
• Use --jetpack--contact-form--text-color variable for border color instead of --jetpack--contact-form--inverted-text-color

These changes fix checkbox styling issues where checkboxes appeared unclickable with white text on dark backgrounds, and ensure the checkbox color settings apply correctly to both the text and checkbox box.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Related to checkbox styling improvements and color consistency issues reported by users.

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

No, this is purely a CSS styling fix.

Testing instructions:

• Create a new Jetpack form with checkbox fields (Multiple Choice Checkbox, Single Checkbox, or Consent field)
• Apply the List style to the form
• Set a custom text color using the "Option Color" setting
• Verify that checked checkboxes display correctly with proper contrast
• Test on both light and dark backgrounds
• Verify the checkmark appears with correct color using the text color variable
• Check that the checkbox border color matches the text color appropriately

Before / After

Before: Checkboxes used background-color: currentColor which didn't provide proper styling and the border used an inverted text color variable.

After: Checkboxes use filter: invert(1) for the checked state and the border uses the correct text color variable, providing consistent and accessible checkbox styling.

[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/form-checkbox-style-solution branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fix/form-checkbox-style-solution

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 a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ 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!

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly:
  • Scheduled release: January 6, 2026

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[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

_{Coverage check overridden by Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR .}

[enejb]

It would be good to include screenshots with these PRs @CGastrell so that it is easier to compare the different implementations.

Trunk:

This PR: The second checkbox in this screenshot is selected checkbox.

I think this PR is getting things pretty close but is somehow still missing something. I was expecting the border to stay the same as trunk. Maybe we need to tweak a few more things here to make it look more like expected? ( it should look like the current trunk implementation)

[CGastrell]

It would be good to include screenshots with these PRs @CGastrell so that it is easier to compare the different implementations.

I'm testing on ~20 themes, pasting before/after seems a bit like not gonna cover all the cases, so everyone can test their own case

[CGastrell]

I was expecting the border to stay the same as trunk

( it should look like the current trunk implementation)

Do we actually know current trunk is the expected output? We keep talking about what's "expected", but seems to me that's just how it looks now on trunk, not necessarily the actual expectation. Besides, these 2 PRs aim for fixing a bug while achieving some consistency.

Also on the topic of "expected", most themes not even have a case for inputs, so I'm not sure there's always an expectation (some do). In a way, we're just paving what the default look should be on our inputs, trying to be consistent and retain readability.

cc @ilonagl @ederrengifo do we have designs on themes and how those should render inputs/checkboxes? That would help a lot.