A topic that surfaces time and time again is whether — and how — to mark required fields on a form.
Required fields, also known as mandatory fields, are questions that must be answered by the form-filler. The opposite of a mandatory field is an optional field; with these questions, form-fillers have a choice.
We’ve written about this issue before. Since then, we’ve worked on more projects, heard even more arguments and read more research and opinions. We’ve also quietly observed the web as it evolves, slowly becoming more familiar, more flexible, more mature.
Coming full circle
Before computers, there were paper forms. Correct us in the comments if we’re wrong, but as far as we know paper forms never included a “required” indicator. There was an implicit understanding that if the question was asked, it had to be answered (unless, perhaps, it had some kind of indication that it was optional).
Then along came the web and at some point, a red asterisk (*) started being used to indicate required fields. (We were unable to find out the origin of the red asterisk being used to indicate “required” – if you know anything about it, please share in the comments.)
The experience of leading user experience researchers suggests that at best, form-fillers vary in their seeing and understanding of the red asterisk. In Caroline Jarrett and Gerry Gaffney’s experience, many people don’t know what it means. On the other hand, in the comments to this blog post by Perficient, David Hamill notes he’s never heard a user misunderstand the red asterisk. But one eyetracking study by CX Partners found no form-fillers looked at the asterisk (see Guideline 5) – perhaps some form-fillers don’t mention a lack of understanding because they don’t even see it (or are embarrassed to admit it).
Moreover, the red asterisk has accessibility issues, and not just for form-fillers that use screenreaders . An asterisk is a symbol, which means there is a layer of abstraction between the thing and what it represents. As Luke Wroblewski says:
We note that the abstraction into a red asterisk could be especially difficult for form-fillers with cognitive impairment.
To maximise usability and accessibility, then, it would be much better to be straightforwardly explicit, and label all fields as either “required” or “optional”. Indeed, Baymard recommend this approach. But we see a number of problems with this method:
- Having “required” or “optional” as part of every field label significantly increases the form’s visual noise, especially if “required” is in red.
- Having “required” or “optional” as part of every field label significantly increases the amount of cognitive processing the form-filler has to do.
- “Required” or “optional” take up valuable space on a small or mobile screen.
- Baymard’s recommendation is based on a small number of research participants who sometimes questioned whether an unmarked question was required or not. Our contention is that these were particularly challenging questions, so they should either be optional, or if required, include explanation to reassure the form-filler.
Add to this the fact that many web forms — e.g. login — actually don’t indicate required fields and work well, and we think it’s time to set a new standard.
Mark only optional fields
To achieve optimal usability and accessibility across the broadest user base, we propose that every web form should mark only optional fields, as follows:
- Have an instruction, at the top of each screen, that says: “All questions must be answered, unless marked (optional).” .
- Do not have any visual markings against required questions.
- Add “(optional)” to the end of the label for every optional question .
The resulting experirence would be even better if you:
- semantically mark required fields with the HTML5 required attribute on the input element and/or set the property aria-required to true ; and
- make the text “(optional)” a less prominent colour (e.g. lighter grey like #646464), so it contrasts slightly with other form elements (but still constrasts sufficiently with the background).
Here’s how this would look:
Figure 1: An illustration of the proposed approach, as seen on a mobile.
Further rationale for only marking optional fields
Step back and think about what we are doing when we mark something in an interface. We are trying to highlight it, to indicate that it’s different from the norm, and that a change of behaviour may be needed.
When someone starts a form, they expect to answer questions and provide information. It’s the very nature of the interaction. Filling out forms is the norm.
Thus, the deviation from the norm is optional fields, and it those fields we need to highlight. With required fields, we want users to continue doing what they expect to do: provide answers. With optional fields, we want the user to know they have a choice they don’t normally have. Hence, we should mark optional fields.
Plus, with the exception of backgrounder forms (see next section) the majority of questions on your form should be required.
Backgrounder forms are the exception
Every rule has at least one exception, and in this case, the exception is what we call “backgrounder” forms. As the name suggests, these are forms that aim to document the background of a situation, which can vary significantly. Examples include:
- a form collecting a person’s financial status, in preparation for a financial planning meeting;
- a form for documenting an accident or incident in the workplace;
- an online dating profile; and
- a form collecting the events that led up to a complaint.
When it comes to required versus optional fields, backgrounder forms are the opposite of other types of administrative forms . On most administrative forms, the majority of questions must be answered, with only a few questions optional. Conversely, on backgrounder forms, there are often only a few questions that have to be answered in every case (e.g. name or date). Because the form has to cater for such a wide range of circumstances, the vast majority of questions are then optional.
Applying the logic that supports marking only optional fields on standard administrative forms, we can see that the best approach for backgrounder forms is to do the reverse and mark only required fields:
- Have an instruction, at the top of each screen, that says: “All questions are optional, unless marked (required).”.
- Have no visual marking against optional questions.
- Have “(required)” added to the end of the label for every required question.
We know that this may introduce some inconsistency between forms that belong to the same organisation. However, we feel on balance, the benefits for usability of each individual form outweighs any confusion that may arise from the inconsistency.
Time for a new standard?
So what do you think? Have we established a sufficiently strong argument for changing the way required and optional fields are indicated? Or is there some major usability or accessibility implication that we haven’t considered? Remembering that we’re looking for a standard that is the best balance of different users, contexts, constraints and goals, leave a comment. We’d also really like to canvass as many views as possible, so if you found this article valuable or thought-provoking, please share it widely.
 Depending on the verbosity setting of the screenreader, the asterisk may be treated as a special character and thus not read out. Also, when in forms mode, the asterisk will be missed if it is not part of the field label.
 The plain English of this instruction is important. Jargon like “mandatory” and “field” are not well understood by the general public. Using plain English can even improve conversion rates (see point 4 of “10 words I’d ban from all websites“).
 It is our [untested] hypothesis that fewer people will answer the optional questions if the “(optional)” indicator is placed at the start of the label instead of at the end. If the indicator is at the start of the label, some form-fillers will not bother to read the question, even through answering it may benefit them. But if the indicator is at the end of the label, the question will be read first, and this may provide more impetus to answer.
 A form can be WCAG 2.0 compliant if only optional fields are marked following the approach described here. Adding aria-required=“true” can further improve accessibility. For more information, see “Aria-required=true: WCAG 2 Compliance versus Best Practice“.
 The two main types of forms are administrative forms and survey forms. Two very different use cases, which in turn often means different design approaches. We hope to write more about this distinction between form types in the near future.