Forms · Compared

Required vs optional fields: how many is too many

A required field must be answered before a form can be submitted or the respondent can move on; an optional field can be left blank. The choice decides whether a missing answer is impossible or merely possible, and every required mark trades a complete dataset against the chance that somebody gives up or invents an answer.

Required marks are the cheapest setting on a form and one of the most expensive in effect, because each one is a point where a person with no good answer must either lie or leave. Getting the balance right is mostly a matter of asking what you would actually do with a response that lacked the answer.

Indunil Asanka · Co-founder

6 min read · Published 13 September 2026

Four ways to handle a question you want answered
Setting	What you get	What it costs	Best for
Required	An answer on every response	Drop outs, and invented answers from people with nothing true to say	Details you cannot act without: contact, consent, the item ordered
Optional	Only the answers people choose to give	Gaps that are hard to interpret in a survey	Extra context, sensitive topics, demographic questions
Required with a not applicable option	An answer every time, including an honest opt out	One more option to read on every question	Survey items that may not apply to everyone
Soft prompt before moving on	A reminder, then a free choice to continue	An extra click for people who skip on purpose	Questions you want answered but will not force

Marking which is which

Two respected style guides give opposite advice, and both are defensible. Nielsen Norman Group recommends marking every required field, preferably with an asterisk, and says marking optional fields as well lightens the load because people no longer have to infer the status of the unmarked ones. The GOV.UK Design System goes the other way: add optional to the labels of optional fields and never mark mandatory fields with asterisks, on the reasoning that government forms should ask only for what they need, so most questions are required anyway. The practical rule that reconciles them is to mark whichever kind is rarer on your form, explain the convention once at the top, and apply it without exception. What fails is a mix of conventions, or no mark at all.

What a forced answer costs

A required question that does not apply to somebody leaves them three options: abandon the form, pick something untrue, or type a dash or a full stop to get past it. The second and third look like real answers in the data, which is worse than a blank because nothing flags them. That is the hidden cost of making everything required on a survey. On a transactional form the logic is different, because a booking without a date or an order without a quantity is useless, and requiring those fields prevents a follow up email that costs more than the extra moment of effort. The distinction to hold onto is between answers the form cannot work without and answers that would merely be nice to have.

How many is too many

There is no safe number, but there is a reliable test. For every required field, ask whether a response missing that answer would be rejected, chased or unusable. If it would, keep it required. If you would happily use the response anyway, the field should be optional, and if you would not miss the answer at all, the question should probably go. Applied honestly, the test usually leaves a contact form with three or four required fields, an application with more, and a feedback survey with very few. A second check is to count how many required fields sit before the first one the respondent actually cares about, since a wall of mandatory administration at the start is where many people quietly give up.

Errors when a required field is missed

Whatever the convention, the form has to say clearly when something was left out. WCAG 2.2 success criterion 3.3.1, at level A, requires that when an input error is detected the item in error is identified and described in text, and it counts required information that was omitted as an input error. So a red outline on its own is not enough: the message has to name the field and say what is missing, and ideally it should appear next to the field as well as in any summary. Keep what the person has already typed. Nothing makes somebody close a tab faster than discovering that one missed question wiped the answers they gave to the other twelve.

How required works in this builder

Every input field has a Required Field switch in its Validation settings, and a required field shows a red asterisk after its label. On a classic form the browser runs its own required check, and pressing submit with a required answer missing brings up a message naming the first field that still needs one. On a conversational form, pressing Next checks the required fields on that screen and asks the respondent to answer the one they missed. The server checks required answers again on every submission, so the rule cannot be skipped by a modified page. There is no soft prompt setting; a not applicable choice is added as an ordinary option. The contact example keeps its phone field optional and says in the label that it is only needed if you chose phone.

Questions people ask

Should a marketing opt in ever be a required field?

No. A required box that must be ticked to submit is not a free choice, and consent that is not freely given is weak consent under most privacy laws. Require agreement to terms that the service genuinely depends on, and keep any marketing permission as a separate, optional, unticked choice that the form works perfectly well without.

How do screen reader users know a field is required?

Through the markup rather than the colour. The HTML required attribute, or an aria required property, tells assistive technology that the field must be filled, and the label itself should carry the word required or the asterisk convention explained at the top of the form. A red asterisk that is purely visual tells a screen reader user nothing at all.

Should the email field be required on a feedback survey?

Only if somebody will actually reply. Requiring an email on a survey that nobody answers personally lowers response rates and makes the survey identifiable for no benefit. A better pattern is an optional field at the end that says a reply will come only if an email is left, which gives people who want contact a way to ask for it.

Is a required field on a skipped screen a problem?

It should not be, and it is worth testing. A required rule should apply only to questions the respondent actually saw. If a branching rule sends somebody past a screen, a required question on that screen must not block their submission. Walk every path of a branched form once before publishing to confirm that nothing unseen stands in the way.

What should a required field error message say?

Name the field and say what to do, in the respondent's language rather than the system's. Enter your postcode works better than field invalid or this field is required, because it tells the person which box and what to put in it. Place the message beside the field, and keep the tone neutral, since a missed question is usually an oversight.

Do required fields make data more reliable?

They make it more complete, which is not the same thing. A required question on a survey guarantees an answer, not a considered one, and forced answers from people with no view add noise that looks like signal. Reliability comes from asking questions that apply to everybody, offering an honest way to opt out, and requiring only what the form genuinely needs.

Make one with forms

The button opens the generator with this use case already described. Change the wording to match your own.

Create a form with OneCraft

Sources

Written and checked by the OneCraft team. Last checked 13 September 2026.