refactor(number-field): revamped number field component

[blunteshwar]

Description

Motivation and context

Related issue(s)

• fixes [Issue Number]

Screenshots (if appropriate)

---

Author's checklist

• I have read the CONTRIBUTING and PULL_REQUESTS documents.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices
• I have added automated tests to cover my changes.
• I have included a well-written changeset if my change needs to be published.
• I have included updated documentation if my change required it.

---

Reviewer's checklist

• Includes a Github Issue with appropriate flag or Jira ticket number without a link
• Includes thoughtfully written changeset if changes suggested include patch, minor, or major features
• Automated tests cover all use cases and follow best practices for writing
• Validated on all supported browsers
• All VRTs are approved before the author can update Golden Hash

Manual review test cases

• Descriptive Test Statement

  1. Go here
  2. Do this action
  3. Expect this result

• Descriptive Test Statement

  1. Go here
  2. Do this action
  3. Expect this result

Device review

• Did it pass in Desktop?
• Did it pass in (emulated) Mobile?
• Did it pass in (emulated) iPad?

[changeset-bot]

⚠️ No Changeset found

Latest commit: 25c1422

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

📚 Branch Preview

• Documentation Site
• Storybook

🔍 Visual Regression Test Results

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

• Spectrum | Light | Medium | LTR
• Spectrum | Dark | Large | RTL
• Express | Light | Medium | LTR
• Express | Dark | Large | RTL
• Spectrum-two | Light | Medium | LTR
• Spectrum-two | Dark | Large | RTL
• High Contrast Mode | Medium | LTR

Deployed to Azure Blob Storage: pr-5595

If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.

[github-actions]

Tachometer results

Currently, no packages are changed by this PR...

[Rajdeepc]

Thanks @blunteshwar for pushing this forward!

Before we dive deeper, let’s take a structured approach to these refactor PRs:

What’s the scope of change?
Let’s define what problem we’re solving—bug fix, refactor, design alignment, or value-add for consumers.

Any API changes?
If yes, we need to:

• Evaluate the value for consumers
• Align on a migration path
• Plan for deprecation (if needed)

Internal changes?
Even if it’s internal-only, let’s assess the impact—especially around test coverage, potential regressions, and long-term maintainability.

Let’s document intent + expected outcome in the PR description as we move forward. Please add if you feel that we should cover here. This can be a generic approach for all the refactor work going forward.

[blunteshwar]

Even if it’s internal-only, let’s assess the impact—especially around test coverage, potential regressions, and long-term maintainability.

Scope of Change
I'm undertaking a major refactoring of the number field component to improve its reliability and maintainability. I'm moving away from a custom number input implementation—where we manually handled parsing, formatting, and validation—and instead adopting the native .

My primary goals with this migration are:

• To reduce bugs caused by manual number formatting and parsing
• To improve accessibility by relying on browser-native behavior
• To reduce the maintenance cost of our current custom logic
• To ensure more consistent behavior across browsers
• This isn't just a bug fix—it's a foundational rewrite of how the number field works.

Long-term Benefits I’m Targeting:

• Fewer bugs from edge-case input handling
• Improved accessibility thanks to native support
• Performance gains from simplified logic
• Easier maintenance and onboarding for future contributors

My Recommended Approach

• Document behavior changes: I’ll clearly specify how the new behavior differs and where consumers might see changes in a RFC doc.
• Support consumers with migration examples: I’ll provide side-by-side code examples and tools to help them migrate easily.
• Invest in comprehensive testing: During and after the transition, I’ll make sure we’re thoroughly covered.