Benefits of a single text field versus multiple text fields

We often come across forms that have multiple fields for what is in essence a single piece of data, like a phone number or credit-card number. Doing so can pose some usability issues if they aren’t marked up in the right way. Would it be better to ask for these chunks of data with single text fields instead?

Note: Please read this article as me pondering about these benefits rather than presenting them as facts. Reflecting on this article now, in 2025, I think I should’ve done more research on this. It would’ve been good if I had posed this more as a question rather than a finding.

You may have come across fields for phone numbers and credit-card numbers that look something like this:

An issue that often crops up with this design style is that not all fields are properly labelled. The code for a phone-number field might look something like this:

<label for="phone">Phone number</label>
<input type="text" id="phone" />
<input type="text" />
<input type="text" />

Screen readers will announce the first field in that example as something like “phone number, edit text”, but the next two fields will be announced as “blank, edit text” because there’s no label associated with either of them. That could be fixed by adding labels for the other two fields:

<fieldset>
  <legend>Phone number</legend>
  <label for="area">Area code</label>
  <input type="text" id="area" />
  <label for="phone-first">Middle three digits</label>
  <input type="text" id="phone-first" />
  <label for="phone-last">Last four digits</label>
  <input type="text" id="phone-last" />
</fieldset>

But that’s quite a bit of code for a simple phone number. There’s also a lot of information for the user to take in and process. You could visually hide the labels, but it’d be a lot simpler—in both code and user interface—if there were only one field to fill in. There are other benefits to using a single field which we’ll discuss later on.

Let’s go through an example with a single form field. In which case you can tell browsers that the field is in fact for a phone number by setting the input’s type to tel. The result is something like:

<label for="phone">Phone number</label> <input type="tel" id="phone" />

On devices with a virtual keyboard, like a smartphone, focusing that field brings up the phone-number keyboard, like so:

Another benefit to using a single field is that a single continuous field is better suited for international phone numbers, like the many telephone-numbering plans in the world that are different from the US system. For example: Dutch mobile phone numbers start with “06” followed by eight digits; UK mobile phone numbers can be up to eleven digits; and landlines in Kota Kinabalu, Malaysia, start with “088” followed by six digits.

A credit-card number are also often subjected to the multiple-text-field treatment. Perhaps this is because they’re visually separated on most credit cards or because it’s rather easy to add that same visual separation to the form.

Such a form might look something like this:

<fieldset>
  <legend>Credit-card number</legend>
  <label>
    First four digits
    <input type="number" maxlength="4" />
  </label>
  <label>
    Second set of four digits
    <input type="number" maxlength="4" />
  </label>
  <label>
    Third set of four digits
    <input type="number" maxlength="4" />
  </label>
  <label>
    Last four digits
    <input type="number" maxlength="4" />
  </label>
</fieldset>

That code is not unlike if someone were to ask for your credit-card number like this:

“Please give me the first four numbers of your credit card.”
“Okay, and now the next four numbers.”
“Thank you, and now the four numbers after that.”
“Right, and now the last four numbers.”

That’s cumbersome. It would be a lot easier if someone were to ask, “Hey, what’s your credit-card number?” and you could respond with said number. The code that maps to that conversation is very similar to that of the phone-number example:

<label for="credit-card">Credit-card number</label>
<input type="number" id="credit-card" />

There’re many different ways to let users select a date: select boxes, an input with a type of date, three separate fields, or a calendar (among others).

We often see the same labelling issue regardless of whether select elements or input fields are used. Let’s look at an example with three separate fields. This code is very similar to the iffy phone-number code from earlier:

<label for="birthday">Birthday</label>
<input type="number" placeholder="DD" id="birthday" />
<input type="number" placeholder="MM" />
<input type="number" placeholder="YYY" />

In this example, the placeholder attribute tells users which field holds each part of the date—but placeholder attributes have a couple of accessibility-related issues like colour contrast and the fact that the placeholder disappears when text is entered. You can read more about the placeholder attribute in HTML5 Accessibility Chops: the placeholder attribute.

A better way to go about labelling the fields would be to use a label for each field, a fieldset, and a legend, like with the phone-number example:

<fieldset>
  <legend>Birthday</legend>
  <label for="day">Day</label>
  <input type="number" placeholder="DD" id="day" />
  <label for="month">Month</label>
  <input type="number" placeholder="MM" id="month" />
  <label for="year">Year</label>
  <input type="number" placeholder="YYYY" id="year" />
</fieldset>

The placeholder-attribute now provides the expected format for each field while the label tells the user which piece of data is requested.

Different date formats are used in different parts of the world: little-endian, middle-endian, and big-endian. Rabid Puffin goes into more detail about these differences in their excellent video on designing a date input for a global audience. But, they can be summarised as follows:

little-endian

Goes from most to least specific: from day to month to year.

middle-endian

Starts with the month followed by the day and ends with the year.

big-endian

Is the reverse of little-endian and goes from least to most specific: from year to month to day. It’s also the ISO standard for date format.

Because of these varying formats it would be rather difficult to ask for a date in a single input field. To solve this, input-elements can have their type-attribute set to date. When this type is properly implemented, browsers can solve these issues by presenting users with the format their system uses.

Sometime you have to support browsers or operating systems that don’t support the input type of date—in those cases it’s probably better to ask for dates in separate input fields. If you have to ask for the date in a single input field it’s important to provide users with the requested format.

Validation is an important part of online forms—we need to make sure we can use the entered data in the backend of our applications. However, we offload this burden onto the user all too often. We request they use certain separators, formats, and character sets. This doesn’t make filling a form easier for users; it makes it easier for developers to handle the entered data.

For certain things—like dates—there’s no getting around this. In other cases though, there’s no need to offload this burden to the user. Karl Groves wrote an article on how to filter non-numerical characters from strings. This is very helpful for things like credit card validation—we know those are sixteen numbers. So, we can filter out everything that’s not a numeric character.

With such a system in place, it doesn’t matter if users add in separators to help them keep their place while entering the data—we can simply strip those. If someone wants to add spaces between numbers in a phone number—because they’re dyslexic for example—they should be free to do so.

In most cases, it’s easier to enter a phone number or a credit-card number into a single field. But if you need to have multiple fields, make sure they’re correctly labelled. Yes, that might mean having labels along the lines of “Third set of four digits” and that sort of thing.

Forms are a hassle even under the best of circumstances—we should strive to make them as easy to use as possible. Ultimately, our goal is to make it as easy as possible for a user to complete the task in front of them. Or as Alice Bartlett put it:

Do the hard thing to make it simple. —Alice Bartlett

First off, I’d like to thank the 24 Accessibility team for this opportunity and their dedication to accessibility as a whole. I’d also like to thank the people that have proofread my article and provided me with feedback. Special thanks go out to Ashley Bischoff, my editor pal, whom has done an amazing job of making this article readable.