fix: Updates number component to have more consistent UX

[thiessenp-cds]

Summary | Résumé

Updates number component to have more consistent UX.

Test

Create a form with a Number component. Try entering a number, it should be read correctly in a screen reader. Try entering not a number, form validation should fail for the Number component.

e.g.

Screen.Recording.2025-01-02.at.1.39.29.PM.mov

[github-actions]

🧪 Review environment

https://47pohtsyxdtssbbbsqptibcxnm0wzqky.lambda-url.ca-central-1.on.aws/

[timarney]

Looks like it's accepting text chars ?

https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint_validation

[thiessenp-cds]

Looks like it's accepting text chars ?

https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint_validation

Form validation would fail if it's not a number like in your example. Do you think more immediate validation or constraints would be helpful?

PS: Oh and Hi :)

[timarney]

I would say we'll need a product decision on this one

cc: @Abi-Nada @srtalbot

[thiessenp-cds]

I would say we'll need a product decision on this one

cc: @Abi-Nada @srtalbot

I added a way to restrict user input to a number. Easy to remove if we decide not to include this.

[timarney]

Looks good -- @connorscarolyns will wait to approve until you have a look as well.

[connorscarolyns]

I think it works ok, It will be interesting to see how it tests. The screen reader announcing might be a bit confusing because it says it's a text field and to enter text, but nothing about it only accepting numbers.

[connorscarolyns]

I also notice that the UK does not use the pattern attribute, and has added a spellcheck false. Do we have reasoning for or against these differences?

[thiessenp-cds]

The pattern attribute is used by JavaScript to validate what’s entered as a number but I can move/hide this in the JavaScript.

We can add spellcheck though if we restrict to only numbers it may not have much value. Still doesn’t hurt.

I think that’s a good point that the input is not announcing itself as a number. So a user could try to enter characters that are not a number and have no idea why it wasn’t entered.

One solution would be to add an aria-label and override the input semantics. This way it would announce as a number.
E.g. without an aria-label

E.g. with an aria-label=”number”
So the accessible name is changed to "number {label text}, edit text"

I wonder if the solution is becoming complex with the added JavaScript to restrict a number and aria to redefine an input text as a number? Vs. Just checking if an input is a number on submit and hopefully that input has hints it should be a number. I’m kind of on the fence.

[thiessenp-cds]

@connorscarolyns actually what if we were to go ahead with the JavaScript to restrict entering to a number and adding an aria-label to identify the input as a number and see what happens in future user tests?

[connorscarolyns]

@thiessenp-cds I like your approach. You may be right about overcomplicating things, but user testing will show if there are issues. I'm fine with it how it is and will log any further concerns when we retest the next time.