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 creates 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.

1. Accessibility

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. 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.

Once the number is parsed by the browser as an exponent, as shown above, and possibly by mistake, t he 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 5.1 attempts to make values with at least 16 digits more readable by inserting commas.

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.