Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PP-5366 - use inputmode and pattern attribute on numeric fields #921

Merged
merged 2 commits into from
Jun 25, 2019

Conversation

jonheslop
Copy link
Contributor

The Design System team have done some accessibility testing on input type="number" and deemed them problematic. They have suggested using

input type="text" inputmode="numeric" pattern="[0-9]*"

instead as documented here alphagov/govuk-frontend#1449

@jonheslop jonheslop force-pushed the PP-5366-update-numeric-fields branch from 58de2c9 to c0fa6d1 Compare June 25, 2019 10:14
The Design System team have done some accessibility testing on `input
type="number"` and deemed them problematic. They have suggested using

`input type="text" inputmode="numeric" pattern="[0-9]*"`

instead as documented here alphagov/govuk-frontend#1449
@jonheslop jonheslop force-pushed the PP-5366-update-numeric-fields branch from c0fa6d1 to 6b6b7f6 Compare June 25, 2019 10:16
Copy link
Contributor

@alexbishop1 alexbishop1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good for the reasons described in alphagov/govuk-frontend#1449, which explains why the new approach is superior to both input type="number" and input type="tel".

Using inputmode="numeric" definitely looks like the right thing to do (why weren’t we using it before?!). I’m aware that of the pattern="[0-9]*" trick used to get the numeric keyboard on iOS Safari (including older versions that don’t support inputmode), so that’s all good too.

I suppose there’s a slight chance that the switch to input type="text" could degrade the virtual keyboard experience on browsers that don’t support inputmode (e.g. Firefox) but users will still be able to enter numbers on the full keyboard.

This change removes the min="1" and max="12" attributes from the month input but we have existing client-side validation that will catch any problems when the focus moves out of the field (I just checked this).

@alexbishop1
Copy link
Contributor

I forgot to say — it would be good to check if this changes anything to do with browser credit card autofill or that fancy feature where iOS Safari offers to read the card number from your physical card using the camera.

@jonheslop
Copy link
Contributor Author

I forgot to say — it would be good to check if this changes anything to do with browser credit card autofill or that fancy feature where iOS Safari offers to read the card number from your physical card using the camera.

Yeah will check this, I think that should be fine as I think that mostly relies on the autocomplete attribute values

@jonheslop jonheslop merged commit 6875f37 into master Jun 25, 2019
@jonheslop jonheslop deleted the PP-5366-update-numeric-fields branch July 16, 2019 09:43
hannalaakso added a commit to adamsilver/govuk-design-system that referenced this pull request Oct 17, 2019
We've done some investigation to show that now in certain
scenarios this is the best way of collecting numeric data from users. We have a
bunch of changes to make to roll this out in GOV.UK Frontend:
alphagov/govuk-frontend#1449 (comment)
After that, we can set this in the input component itself instead of using the
`attributes` object.

Following our above investigation, GOV.UK Pay introduced this change for
collecting credit card details:
alphagov/pay-frontend#921 They haven't seen
any issues so we are sufficiently confident to make the same change
in the Design System.

This is only applied to sort code and account number as the other data collected
is alphanumeric.

Tested on iOS 12 and 13, Android 9 and 8.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants