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

Update date input to use type=text and inputmode=numeric #1704

Merged
merged 3 commits into from
Jan 20, 2020

Conversation

36degrees
Copy link
Contributor

@36degrees 36degrees commented Jan 20, 2020

Within the date input component the individual inputs look like this:

<input […] type="number" pattern="[0-9]*">

We set the input to type="number" so that Android browsers display a numeric keypad keyboard when the input is focussed.

iOS uses the full alphanumeric keyboard for type="number", so we add pattern="[0-9]*" which triggers the numeric keypad there too. This is technically invalid HTML, as the pattern attribute only applies to inputs of type text, search, url, tel and email, but is not known to cause any real-world issues.

However, there are a number of known issues with inputs of type="number" – many of which were found in research and documented by @hannalaakso :

(Bugs have been filed where appropriate)

In testing, using <input […] type="text" inputmode="numeric" pattern="[0-9]*"> mitigates these issues, with some minor drawbacks:

  • Between iOS 12.2 and 13.0, the numeric keypad with punctuation is displayed instead of the numeric keypad. Versions prior to 12.2 do not support inputmode, thus fallback to the pattern attribute, and continue to show the full numeric keypad. iOS 13 updates inputmode="numeric" to use the numeric keypad without punctuation.
  • Firefox, UC Browser (and older versions of other browsers) on android support neither inputmode nor pattern, and so will use the full alphanumeric keypad until those browsers introduce support for inputmode. (Note: neither Firefox nor UC browser on Android are listed in our own browser support matrix nor the service manual)

Closes #1700

@govuk-design-system-ci govuk-design-system-ci temporarily deployed to govuk-frontend-review-pr-1704 January 20, 2020 14:32 Inactive
Copy link
Contributor

@NickColley NickColley left a comment

Choose a reason for hiding this comment

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

Great work, long time coming. Love the list of references that back this change.

@govuk-design-system-ci govuk-design-system-ci temporarily deployed to govuk-frontend-review-pr-1704 January 20, 2020 15:33 Inactive
@govuk-design-system-ci govuk-design-system-ci temporarily deployed to govuk-frontend-review-pr-1704 January 20, 2020 15:42 Inactive
36degrees and others added 3 commits January 20, 2020 15:51
Within the date input component the individual inputs look like this:

```
<input […] type="number" pattern="[0-9]*">
```

We set the input to `type="number"` so that Android browsers display a numeric keypad keyboard when the input is focussed.

iOS uses the full alphanumeric keyboard for `type="number"`, so we add `pattern="[0-9]*"` which triggers the numeric keypad there too [1]. This is technically invalid HTML, as the pattern attribute only applies to inputs of type `text`, `search`, `url`, `tel` and `email` [2], but is not known to cause any real-world issues.

However, there are a number of known issues with inputs of `type="number"`:

- they silently discard non-numeric input in Chrome [3] (except the letter 'e')
- users can accidentally increment or decrement the number using the arrow keys without realising [4]
- users can accidentally increment or decrement the number using the scroll wheel on the mouse or the scroll gesture on their trackpad [5]
- they appear as unlabeled in NVDA's element list [6]
- in NVDA's object navigation they are seen as a spin button which has an edit field and two buttons inside. Those buttons are unlabeled, but decrease/increase the value [7]
- when tabbing to the field NVDA using pressing nvda+tab they are reported as unlabeled edit fields [7]
- users of Dragon Naturally Speaking cannot dictate into them as expected [8]

(Bugs have been filed where appropriate)

In testing, using `<input […] type="text" inputmode="numeric" pattern="[0-9]*">` mitigates these issues, with some minor drawbacks:

- Between iOS 12.2 and 13.0, the numeric keypad with punctuation is displayed instead of the numeric keypad. Versions prior to 12.2 do not support `inputmode`, thus fallback to the `pattern` attribute, and continue to show the full numeric keypad. iOS 13 updates inputmode="numeric" to use the numeric keypad without punctuation.
- Firefox, UC Browser (and older versions of other browsers) on android support neither `inputmode` nor `pattern`, and so will use the full alphanumeric keypad until those browsers introduce support for `inputmode`. (Note: neither Firefox nor UC browser on Android are listed in our own browser support matrix [9] nor the service manual [10])

---

[1]: http://bradfrost.com/blog/post/better-numerical-inputs-for-mobile-forms/
[2]: https://html.spec.whatwg.org/multipage/input.html#input-type-attr-summary
[3]: #1449 (comment)
[4]: #1449 (comment)
[5]: http://bradfrost.com/blog/post/you-probably-dont-need-input-typenumber/
[6]: alphagov/reported-bugs#41
[7]: nvaccess/nvda#9675 (comment)
[8]: alphagov/reported-bugs#34
[9]: https://github.com/alphagov/govuk-frontend#browser-and-assistive-technology-support
[10]: https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices#browsers-to-test-in

Co-authored-by: Colin Oakley <colin@htmlandbacon.com>
Co-Authored-By: Nick Colley <nick.colley@digital.cabinet-office.gov.uk>
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.

Update the date input to use text inputs with a numeric input mode
3 participants