The right keyboard in mobile forms: type, inputmode and autocomplete

In short

In a mobile form, a keyboard opens every time you tap a field. Which one is up to the browser. You give it a hint with the input’s attributes.

A wrong keyboard looks like a small problem. But it repeats in every field of the form. General form rules are on the form design page. This page covers only the keyboard.

Four attributes, four jobs

These four attributes are often confused, yet each controls something different.

• type says what the data is. According to MDN, the email and url types check the format before submitting; tel doesn’t, because phone numbers vary so much from country to country.
• inputmode only chooses the keyboard. MDN says it clearly: this attribute doesn’t set any validation rule. The default value is text.
• autocomplete tells the browser the field’s purpose. The browser then suggests a saved email or ZIP code.
• enterkeyhint chooses the label of the Enter key. If it is missing, the browser can choose a label based on inputmode, type or pattern.

MDN lists eight values for inputmode. I have shortened the descriptions:

For the values tel, email, url and search, MDN gives the same advice. If the field really asks for this data, use the matching type.

For enterkeyhint, MDN lists seven values: enter, done, go, next, previous, search and send. In fields in the middle of a form I use next, in the last field done or send.

Choose a field type

Each of the six fields below is a real input. Open the page on your phone and tap a field, and you see how the keyboard changes. Switch to the bad example and the input’s attributes change too.

A common mistake is type="number" for ZIP codes and routing numbers. People choose it so the number pad opens, but get unwanted behaviour with it. I describe that below.

Fields in the United States

MDN defines the values but doesn’t say which one to choose for US fields. The table below is my suggestion: the format of the fields is documented; the choice of attributes is mine.

Phone. The United States is part of the North American Numbering Plan, with country code 1. Numbers have ten digits: a three-digit area code and a seven-digit local number. Users write them as “(555) 123-4567”, “555-123-4567” or “5551234567”. Accept all of them.

According to MDN, tel-national is a number without the country code. If you also accept international numbers, use tel: MDN describes it as a full number including the country code.

Routing number. An ABA routing number has nine digits. There is no value for it in MDN’s list of autocomplete values. inputmode="numeric" is enough for the number pad.

ZIP code. A ZIP code has five digits; the ZIP+4 form adds four more. Some ZIP codes start with 0, such as 01002 for Amherst, Massachusetts, and that 0 mustn’t be lost. MDN also counts postal codes among the values that type="number" doesn’t suit.

Card number. MDN names credit card numbers as another value that consists only of digits but isn’t really a number. Card numbers are usually written in groups of four; the form should allow typing them that way.

According to MDN, pattern has to match the whole value. Also describe the format in visible text at the field. MDN considers that essential for accessibility.

The type="number" trap

According to MDN, the number type is meant only for numbers that are incremented and decremented. It doesn’t suit values that consist only of digits but aren’t really a number. MDN names postal codes and credit card numbers as examples.

The same page names two risks. Users can change the number by accident while trying to do something else. And if they type something that isn’t a number, they don’t see clearly what they did wrong.

MDN recommends type="text" together with inputmode="numeric" and a pattern. One more note: the pattern attribute doesn’t work with the number type.

For amounts, use decimal, not numeric. numeric only promises 0-9, and the decimal key for the cents may be missing. decimal also shows the decimal separator of the user’s language.

My note

In audits I also look at forms on a phone and note the keyboard as a point of its own. Most often I find that every field opens the same letter keyboard. The developer usually wrote type="text" and moved on.

The second most common mistake: autocomplete="off" on the email and phone fields of the sign-up form. According to MDN, off stops the browser from filling in the value, and the user types everything by hand. I only use this value in fields such as a routing number that the browser doesn’t know anyway.

Once the keyboard is right, another problem shows up: the open keyboard covers part of the screen. To keep fields and buttons easy to tap, see the touch target page. When error messages should appear is described on the inline validation page.

A note on accessibility

WCAG 2.2 success criterion 1.3.5 Identify Input Purpose is level AA. If the purpose of a field that collects information about the user is one of the input purposes listed in the standard, it must be programmatically determinable. The W3C’s sufficient techniques include the HTML autocomplete attribute.

The W3C sees autofill as an important help for users with memory problems or dyslexia, and users with motor impairments type less. I see the right keyboard as part of the same work. All the criteria are covered in the WCAG guide.

autocapitalize changes nothing on a physical keyboard; it affects virtual keyboards and methods such as voice input. According to MDN, letters aren’t capitalised anyway with the email, url and password types. So you don’t need autocapitalize in the email field.

Checklist

Before a form goes live, I tap every field on a phone one by one and go through this list.

• The phone field has type="tel", and the phone keypad opens.
• The email field has type="email", and the email keyboard opens.
• Fields for routing number, ZIP code and card number don’t use type="number".
• In the amount field, the keyboard shows the decimal separator.
• Fields with personal information have the right autocomplete value.
• Next to a field with a pattern, the format is described in text.
• In the last field, the Enter key has a label that fits finishing.

If you want me to do this check: the UX audit includes the mobile points too. If you check yourself, start with the UX audit checklist.