You might reach for <input type="number">
when you’re, you know, trying to collect a number in a form. But it’s got all sorts of issues. For one, sometimes what you want kinda looks like a number, but isn’t one (like how a credit card number has spaces), because it’s really just a string of numbers. Even more importantly, there are a variety of screen reader problems.
Hanna Laakso documents the problems for GOV.UK. This is what they landed on:
<input type="text" inputmode="numeric" pattern="[0-9]*">
The inputmode
attribute is pretty great, and we have a deep dive on that.
Phil Nash came to (almost) same exact conclusion, and blogged about improving the experience of a two-factor auth code input on the Twilio blog:
<input
type="text"
name="token"
id="token"
inputmode="numeric"
pattern="[0-9]*"
autocomplete="one-time-code"
/>
That last attribute is interesting and new to me. It means you get this super extra useful experience on browsers that support it:

There are other autocomplete values, as Phil writes:
There are many autocomplete values available, covering everything from names and addresses to credit cards and other account details. For sign up and login there are a few autocomplete values that stand out as useful hints:
username
,new-password
,current-password
.
Browsers and password managers have very good heuristics to find login forms on web pages, but using theusername
andcurrent-password
values make it very obvious.
I’ve seen a couple of post in response to the gov.uk article and they all seem to have the same issue; that the value they are trying to collect is not a number, it’s a numeric string.
I think a better title for this article would be “ What to Use Instead of Number Inputs When You Are Not Asking for a Number”
I feel like I make myself clear in the opening paragraph.
Such a classic issue. Brad from a year ago: https://bradfrost.com/blog/post/you-probably-dont-need-input-typenumber/
What is the “last attribute” you are referring to? (auto-complete doesn’t seem to have any effect on the input type that I could see)
I ran a quick test here:
The input options (for on-screen keyboard) results varied quite a bit from Firefox/Chrome on Android and iOS Safari (only tested on iPad) .
It was so inconsistent that I would not yet rely on these settings yet for a specific input filtering or result. (which is too bad)
But it seems like we are getting closer to a “less code” method of helping us coders do front end validation.
Yes I mean
autocomplete="one-time-code"
. Might be a little hard to test that unless you can open it on a device and shoot yourself a text in the format of one of those 2-factor auth codes.Worth to mention that using inputmode=”decimal” on Android can be a mess. OEMs can use their own keyboards and some of them don’t have commas, periods and minus keys and the user will not be able to type what they need.
The support gets better in new Android versions but it should be tested extensively with different vendors.