Update date input to use type=text and inputmode=numeric
#1704
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
govuk-design-system-ci
temporarily deployed
to
govuk-frontend-review-pr-1704
NickColley
reviewed
Jan 20, 2020
NickColley
approved these changes
Jan 20, 2020
govuk-design-system-ci
temporarily deployed
to
govuk-frontend-review-pr-1704
govuk-design-system-ci
temporarily deployed
to
govuk-frontend-review-pr-1704
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>
36degrees
force-pushed
the
date-input-type-text-inputmode-numeric
branch
from
eb6857a
to
c4897c4
Compare
This was referenced Jan 20, 2020
Merged
vanitabarrett
changed the title
type=text and inputmode=numeric
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Within the date input component the individual inputs look like this:
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 addpattern="[0-9]*"which triggers the numeric keypad there too. This is technically invalid HTML, as the pattern attribute only applies to inputs of typetext,search,url,telandemail, 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:inputmode, thus fallback to thepatternattribute, and continue to show the full numeric keypad. iOS 13 updates inputmode="numeric" to use the numeric keypad without punctuation.inputmodenorpattern, and so will use the full alphanumeric keypad until those browsers introduce support forinputmode. (Note: neither Firefox nor UC browser on Android are listed in our own browser support matrix nor the service manual)Closes #1700