Why the GOV.UK Design System team changed the input type for numbers

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.

Large buttoned, easy to use number keypad on Android

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.

1. Accessibility

We found that <input type="number"> :

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

3. Letters 

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.

4. Scrolling 

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.

The solution

Using <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 now updated the date input component and the rest of the relevant patterns.

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.