Change Proposal: Restrict keystrokes in `NumberInput` to characters valid for the selected `numberMode`

[zoharma]

What is being proposed?

As discussed in Atlas #143, the NumberInput currently accepts any keystroke into the underlying TextField and only flags invalid content after the fact. A user can type letters, symbols, multiple decimal points, etc., and only discovers the problem from the "Invalid input" helper text.

Proposal: filter keystrokes/paste input as they happen, so only characters that could ever be valid for the active numberMode are accepted:

• Natural: 0-9
• Integer: 0-9, +, -
• Floating: 0-9, +, -, .
• Scientifc: 0-9, +, -, ., e/E

Why is this needed?

• A natural mode field currently lets a user type -5, rejecting it only after the fact. Blocking - at keystroke time prevents that error state from being reachable at all.
• For integer/floating/scientific, - must stay typeable (including mid-entry, e.g. - alone or -1.).
• Filtering at input time avoids the most common invalid keystrokes (letters, symbols) ever reaching numberText. It doesn't catch positionally-invalid strings like 12-3 or 1.2.3, and those still rely on the existing whole-string validation on blur/submit.

Known limitations

Dropping a keystroke silently (character never appears) gives no feedback to screen reader users, unlike the current visible error state. The implementation should pair the filter with some non-visual signal so this isn't a regression for assistive technology users.

What will change?

NumberInputText filters out characters that are not in the allowed set for the active numberMode before they're accepted. When a keystroke is rejected, the field gives a lightweight signal that something happened (e.g. a brief visual cue, and an aria-live="polite" announcement so screen reader users aren't met with silence). Whole-string validation is unchanged. No new props required.

Interface changes (if any)

None required by default. Optional escape hatch if any keys are desired.

Breaking change?

• Yes
• No

Next steps

A maintainer will review this issue.
If accepted, it will be marked as accepted and a PR may then be opened.

[zoharma]

At the same time, I'd like to propose that the helper text should pair with the keystroke restriction change, rather than the current catchall "Invalid input". It can also be used as a helper text rather than as an error.

Suggestions are:

• Natural: "Enter a whole number (e.g. 42)",
• Integer: "Enter a whole number, positive or negative (e.g. -42)",
• Floating: "Enter a decimal number (e.g. 3.14 or -0.5)",
• Scientific: "Enter a number, optionally in scientific notation (e.g. 1.5e-3)",

[EmsArnold]

The current helper text will (by default) show any limits on the field: i.e. "A scientific number. Limits: -14.5 to 14.5 ". Currently these are hard coded, ideally they would be taken from the device dynamically in the future.

For users this is quite useful as they can see whether their intended move should complete or not (imagine this is an input for a motor position). Currently when you try to move (depending on how the scannable is defined), you need to wait for the movement to fail. It would be good to keep these limits optionally visible for users.