To provide users with a good service, government organisations usually need to collect data. Lots of data. The GOV.UK Design System team publishes patterns and components that let users enter their data in an easy and accessible way. The last thing we want to do is create barriers to users completing a task and force them to find an alternative method of using the service, such as phoning a helpline.
Numbers are one of the most commonly asked for pieces of data, typically used in dates. We know from user research that some users prefer the large buttoned number keyboard (resembling a telephone keypad) for entering numbers on mobile. Until now, the GOV.UK Design System date input component used the HTML element
<input type="number"> to provide this number keypad when a user enters dates.
However, we recently moved away from
<input type="number"> to
<input type="text" inputmode="numeric" pattern="[0-9]*"> and published new guidance on how to ask users for numbers.
Why type=number is problematic
Although we have user research from 2017 that didn’t flag any major issues with
<input type="number">, we identified many usability problems with this input type.
We found that
<input type="number"> :
- cannot be dictated or selected when using Dragon Naturally Speaking
- appears as unlabeled in NVDA's element list
- appears as a spin button in NVDA's object navigation, which has an edit field and two buttons inside - those buttons are unlabeled, but decrease/increase the value
- is reported as unlabeled edit field when using nvda+tab
2. Incrementable numbers
It's reasonable to assume that
<input type="number"> can be used for collecting any numeric data: it contains the word “number”, after all. However, a note in the HTML specification states that
<input type=”number”> is “not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number”.
This means that
<input type="number"> can only be used for incrementable numbers, such as dates or the number of people in a household. Using
<input type="number"> for collecting numbers that are not incrementable can cause problems with browsers validating them in that way.
For example, browsers attempt to round large numbers when incrementing or decrementing (pressing up or down key), and in the case of very large numbers they are converted to exponential notation.
Chrome 79.0: type=number displays large numbers in exponential format if user presses the up or down arrows on their keyboard
Once the number is parsed by the browser as an exponent, as shown above, and possibly by mistake, the action cannot be reversed by the user. This could confuse users.
If users access your site using older versions of Safari,
<input type="number"> can also be problematic when collecting values of 16 or more digits. In Safari 6, the browser rounds the number when a user leaves the field, so no mistake with up or down keys is required.
Safari 6 rounds the last digit on blur
Safari 5.1 attempts to make values with at least 16 digits more readable by inserting commas.
Safari 5.1 attempting a more human readable number on blur
The HTML spec states that when using
<input type="number">, “user agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number”. The web and Android versions of Chrome implement this by silently discarding all letter input except the letter ‘e’.
This means users are not given feedback on what type of characters
<input type="number"> accepts, and assistive technologies don’t alert the user that their input has been silently discarded.
Users can accidentally increase or decrease the number using the scroll wheel on the mouse or the scroll gesture on their trackpad. This feature can be useful when collecting countable data but bad if entering data such as passport numbers.
<input type="text" inputmode="numeric" pattern="[0-9]*"> allows for a degree of separation between how the user enters data (“input mode”), what the browser expects the user input to contain (type equals number), and potentially how it tries to validate it.
Prior to 2019 there wasn’t enough browser support, especially on mobile devices, for us to feel confident in rolling this out instead of using
<input type="number">. However the
inputmode attribute is now supported by all the mobile browsers we test in.
We still include the
pattern attribute for backwards compatibility with older iOS devices.
We’ve also published some guidance to help users to understand how to collect numbers in HTML forms.
Finally, we’ve proposed a change to the HTML spec guidance to cross reference
inputmode when using
<input type="text"> with content that is only numbers.
You can take a look at the GOV.UK Design System backlog to see what else we’re working on.
If you're interested in learning more about changes like these, listen to the February episode of the GDS podcast.