A form is made up of a collection of inputs. Most of the time, all you’re going to need is a few text inputs, an email field, and a submit button.
As different platforms and builders make it easier to make forms, they make a bunch of other fields available to you. Sometimes they’re modifications of a regular text input. Name fields, for example, will usually add in the autocomplete values that match up. Sometimes they’re HTML fields and sometimes they’re custom fields created by the plugin or builder.
It’s reasonable to assume that the platforms and builders are giving you the fields that they know are fully tested, that they are all totally fine to add. Unfortunately that’s not actually the case, and it can be difficult to know what is actually a field you can and should use.
So here’s a breakdown of form fields and when to use them.
Basic Fields
As mentioned, your main input type is going to be the general text input. It’s the most straightforward way to have someone add their information, and you really can’t go wrong with it.
You also have your submit input type, which submits the form and sends the data where it needs to go. You have one submit button per form placed after all of the other fields.
You can also sometimes add hidden fields for information that you want to send along with the form but that the person filling out the form doesn’t need to edit or interact with.
The textarea can be a great option for when you expect someone to give a longer answer. This helps someone see their whole answer without having to scroll or navigate back and forth through the text. Avoid limiting the character count unless it’s absolutely necessary, since it does require additional testing to make sure it’s accessible and not super invasive.
Useful Fields
There’s also a collection of fields that are really useful to use as you need them: email, tel, and url. They’ll often bring up a different type of keyboard on some devices and informs autocomplete and autofill values to help make forms easier to fill out.
The password field is great when it makes sense to use it, but if you can, implement a visibility toggle so someone can see what they’re typing in if they want to.
The number field is also useful, but it should only be used when you specifically need a number, usually to do some sort of calculation with. A text field would be fine most of the time.
Using the search input for a search form is also a great choice because it can provide a few extra things depending on the browser to make it easier to use.
The tel field
The phone number field is the one that the builders and plugins will most often mess with. They’ll add input masks for formatting, and sometimes a country selection that would hopefully then change that input mask to match that country’s phone number format.
Most of these things aren’t necessary. Just let someone type in their phone number. If you do decide to include any of those things, you’re going to need to fully test them.
Fields With Choices
There are generally three options when it comes to giving someone multiple values to choose from: checkboxes, radios, and select boxes. Each one has its place, and they each have a specific way that they should be coded.
Checkboxes
This is the field you use when you want to allow someone to choose more than one. It is also used for things like accepting terms.
As for the code, checkboxes need to properly implement fieldset and legend, which is the part most form plugins miss.
Radios
When you need someone to select just one option from an available list, your go-to is going to be the radio buttons. Try to order them in a way that makes sense for the field.
Radios also need to properly implement fieldset and legend, and just like with checkboxes, is often missing.
Selects
In most cases, it’s going to be better to use radios rather than the select box, since radios let you see all the options at once and can be a little easier to review.
But for a longer list of options, it can sometimes be overwhelming to have all those options visible at once. Make sure to organize the options in a way that makes sense. You can also include optgroup, which is a type of title for a group of options.
And for a really long list of options, it’s helpful to include the ability to search the list, though this would need to be fully tested before using, since that type of feature would be custom and not part of the standard HTML select box.
Range
This isn’t a common field, and most of the time it’s going to be better for people trying to fill out the form if they can just enter their answer or choose from a list of options. But most of the time, the range field is fine to use if a situation calls for it.
They need to be styled well, should display the currently selected value, have a big enough thumb and track area, and have clear labels not only for the field itself but describing the minimum, maximum, and how big the step is.
Other Options for Choices
Sometimes forms will give the option for a version of a multi-select, usually something that looks like a select box but has the checkboxes inside instead. These fields usually include some kind of searching aspect which can be useful if you have a very long list of options or if you have limited space like in filter-type forms.
But these types of fields aren’t regular form fields, they’re a custom field created by the plugin that need to be fully tested before they can be used.
There is a built-in version of a multi-select, but it’s not very intuitive and requires someone to know the specific combination of keys and clicks to use. Use checkboxes instead of a default multi-select field.
Upload Fields
Make sure you’re describing all of the requirements before the field. Include if only some file types are allowed, if there’s a size limit, or if someone can only upload one file at a time. Validation for these fields is often done in at least a semi-custom way, so these fields need to be fully tested before they’re used.
Dates
There are a number of types of fields for dates, but most of the time they’re either hard to use or the datepicker is not accessible at all. Just use a text field. Let someone type in the date they want.
If you need dates in a specific format, consider using separate text boxes that have labels for their specific portion of the date: one for month, one for day, and one for year. If you’d like to provide a datepicker, make it optional.
This is also a really common place for builders and plugins to add in masking to attempt to format a date in a specific way which needs to be fully tested before using.
Other Fields
Reset
There’s a reset button that form builders or plugins will sometimes provide, which should be used sparingly. Only use it for really long forms, make sure there’s some form of confirmation before erasing everything, and style it so it looks different from the submit button.
Color
The built-in color field is going to vary heavily based on the browser and operating system, and some of these implementations are definitely not accessible.
Sometimes builders and plugins will implement their own version of it, which would need to be fully tested. Ideally these fields would work the same way a date should work: it’s a text field with an optional color picker.
Wrapping Up
The big takeaway here is that forms need to be tested. Most of the time you’ll be using the basic form fields and don’t have to worry too much about whether those fields are accessible.
When you need to let someone choose an option, pick the best field type. If you need to use more specialized field types, that’s when more in-depth testing is needed.
Most of the time these fields are going to be very hard to fix if the builder or plugin doesn’t implement it correctly, so test as much as you can before you build out all your forms.
