fix: Extend resize handle pointer target to 24px minimum

[Harsh-Anand-Singh]

Description

Extends the pointer target of the resize handle (handle-resize-area in the internal drag-handle component, used by the code editor's resize control) to a minimum of 24x24px to meet WCAG 2.5.8 Target Size (Minimum).

The extension is a transparent ::after pseudo-element anchored to the handle's bottom-right corner, so it grows only up and left. The visible size of the handle is unchanged, and the extension never overlaps interactive elements below or to the right of the handle. The focus ring already uses ::before, so there is no conflict.

Related links, issue #, if available: n/a

How has this been tested?

• npx jest -c jest.unit.config.js src/internal/components/drag-handle — all 147 unit tests pass
• stylelint on the changed file passes
• Manually verified the enlarged hit area in the dev pages

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.64%. Comparing base (4617f38) to head (2159c03).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4896   +/-   ##
=======================================
  Coverage   97.64%   97.64%           
=======================================
  Files         958      958           
  Lines       31247    31247           
  Branches    11536    11536           
=======================================
  Hits        30510    30510           
  Misses        730      730           
  Partials        7        7           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[YueyingLu]

Is it expected to change the size regardless one-theme or not?

[mxschll]

Does this overlap with other elements on a page?

[Harsh-Anand-Singh]

No. The pseudo-element is anchored to the handle's bottom-right corner and only grows up and left, into the component's own surface, it can never extend below or to the right of the handle.

[Harsh-Anand-Singh]

Is it expected to change the size regardless one-theme or not?

Yes, that's intentional. The audit happened to surface it under one theme, but it's a pre-existing gap in all themes, so the fix applies everywhere. Since the extension is invisible there's no visual change in any theme either.

[mxschll]

The icon is 16x16, but now we have a clickable area of 24x24. Should we increase the icon too? Otherwise I can start clicking and dragging at an invisible space.

[Harsh-Anand-Singh]

The invisible area isn't mystery space. Hovering anywhere in the extended area shows the resize cursor, like a pointer landing 4px off the icon was almost certainly aiming at it; starting the resize there is the expected outcome, not a surprise.

[mxschll]

It was pretty surprising to me.

[mxschll]

It was pretty surprising to me.