Somewhere near the top of most forms is a line of small grey text saying that an asterisk indicates a required field. Below it are twelve fields, eleven of them carrying an asterisk. The line is doing almost no work, and the eleven asterisks are doing something nobody intended: telling the visitor that this form is going to be a lot of effort before they have read a single label.
The marking question looks like a detail and it is not. It sets the perceived length of the form, it decides whether people using a screen reader know what is expected, and it is one of the few form decisions that is cheap to change on an existing form.
What the asterisk actually communicates
The asterisk is a convention, and conventions are only readable by people who hold them. Most people who fill in forms regularly do hold this one. Not everyone does, and the ones who do not are disproportionately the people a form most needs to succeed with: someone applying for something for the first time, someone on an unfamiliar device, someone whose first language is not the language of the form.
This is why the key matters. An asterisk with no explanation anywhere on the page is a symbol with no defined meaning. The convention is strong enough that most people guess correctly, but guessing is not the same as knowing, and the cost of the explanation is one line.
Where the key usually fails is placement. Put at the very top of a long form, it has scrolled out of view by the time the first asterisk appears, which is the moment it is needed. On a form with sections, it needs to be near the fields rather than in a preamble. On a form of one question per screen, a key at the start is useless by the second screen, and the marking has to be self describing instead.
The other thing to know about the asterisk is what assistive technology does with it. A bare asterisk in a label is a punctuation character, and how it is announced varies by screen reader and by verbosity setting. It may be read as "star", read as "asterisk", or skipped entirely. That is not a reason to avoid the symbol. It is the reason the symbol cannot be the only place the requirement is recorded, which brings the question round to the markup rather than the visual treatment.
Mark the minority
The default assumption is that required fields get marked. The better rule is that whichever set is smaller gets marked, because the marker is there to carry an exception and an exception on eleven fields out of twelve is not an exception.
Three cases follow from that.
Mostly required, a few optional. Mark the optional ones, with the word Optional next to the label. This is the situation on most application and registration forms, and switching the marking around does two useful things at once. It removes a screen full of asterisks, and it reads as permission rather than demand. A person scanning the form now sees which questions they are allowed to skip, which is information they can act on.
Mostly optional, a few required. Mark the required ones. A survey where only the email address is needed is the clear example.
Everything required. Mark nothing, and say so once in a sentence above the form. Marking every field is pure noise, and the asterisk column makes the form look longer than it is.
The word Optional is worth preferring over an asterisk in the first case, because it needs no key. Text that says what it means survives the absence of the legend, survives a screen reader reading the label out of context, and survives someone arriving at the middle of a long form from a link.
Ways to mark, compared
| Marking | Needs a key | Read by a screen reader | Best for |
|---|---|---|---|
| Asterisk on required labels | Yes | Varies, may be skipped | Forms where required fields are the minority |
| The word Required on labels | No | Yes | Short forms, and anything unfamiliar to the visitor |
| The word Optional on labels | No | Yes | Forms where nearly everything is required |
| Colour on the label only | Yes, and still fails | No | Nothing |
| A sentence above the form, no per field marker | Not applicable | Yes | Forms where every field is required |
The row worth dwelling on is the fourth. Colour is the marking that feels tidiest in a design file and conveys the least. Beyond the obvious problem for anyone who cannot distinguish the hue, colour carries no information at all to a screen reader, in a printed copy, or on a screen in bright sunlight. Guidance on required fields is explicit about this: where a form mixes required and optional controls, the required ones should be indicated with a treatment that does not rely solely on colour, typically descriptive text or an icon, and the presentation should be consistent and visible to all users.
Colour on top of text is fine. Colour instead of text is not a marking at all.
The second row deserves a note too, because the word Required on every label is the marking teams reach for when they have been told asterisks are bad. It is more readable than an asterisk and it takes far more space, which on a long form produces a column of repeated text that is its own kind of noise. It works well on a short form and badly on a long one, and that is the whole of the difference between it and the third row.
There is also a placement decision hiding inside every option. A marker belongs in the label, not floating beside the input, because the label is what gets announced with the field and what stays associated with it when the layout reflows on a narrow screen. A marker placed after the input is read too late to be useful, and one placed in the help text below can be missed entirely by anyone scanning down the labels.
The markup that carries the meaning
Visual marking tells sighted visitors what is expected. The markup tells the browser and assistive technology, and it is a separate job that has to be done as well rather than instead.
On a semantic control, the attribute is required. It is a Boolean attribute, so its presence is what counts, and if present the person must supply a value before the owning form can be submitted. It is supported on the text, search, url, tel, email, password, date, month, week, time, datetime local, number, checkbox, radio and file input types, and on select and textarea elements. Along with blocking submission, it conveys to assistive technology that the control needs a value, and it produces native error messaging in some browsers when a submission is attempted without one.
It also gives styling for free. The :required pseudo class matches any of those controls that carry the attribute, and :optional matches the ones that do not. That means the visual marker can be generated from the same source of truth as the behaviour, rather than being typed into a label by hand where it can fall out of step. A form where the asterisk in the label says required and the input has no attribute is a form that will let the field through empty, and the reverse is a form that blocks submission with no visible reason.
For controls built out of non semantic elements, such as a div with a checkbox role, the equivalent is aria-required="true". It conveys the same meaning to assistive technology, and it can be used on ordinary HTML form elements too rather than only on elements with an ARIA role assigned. What it does not do is change anything about behaviour. ARIA modifies the accessibility tree and nothing else, so a custom control marked this way still needs JavaScript to actually prevent submission, manage focus and report the error. Where the pseudo classes are unavailable because the control is not a real input, an attribute selector on [aria-required="true"] does the styling job instead.
The order of preference is short. Use a real form control with the required attribute. Reach for the ARIA attribute only when the control could not be a real one.
When marking stops mattering
Three situations where the whole question dissolves, and where adding markers makes the form worse.
A login form. Both fields are required and there is nothing to distinguish. An asterisk on the username and password fields of a sign in screen is a marker with no exception to carry.
A single field form. An email capture box, a search field, a one question poll. If there is one field and pressing the button without it will fail, the marker is redundant.
A form where every field is required. Covered above, and worth repeating because it is the most common case on application and intake forms. One sentence above the form stating that everything is needed does the job, and it removes a column of symbols that made the form look twice as long.
In all three, the markup still matters. The visual marker is what becomes unnecessary, not the attribute, because the attribute is what tells assistive technology and the browser what is expected.
The marker is not the fix
It is worth naming what marking cannot do. If a form has eleven required fields and people are abandoning it, no marking scheme will save it. The asterisks are not the problem. The eleven fields are.
This is where the marking question becomes useful rather than cosmetic, because counting the asterisks is a fast audit nobody has to be convinced to run. Every one is a field somebody decided nothing could proceed without. Going through them and asking whether that is still true usually removes two or three, and each one removed is worth more than any change to how the rest are labelled.
The fields that come off the required list rarely stop being wanted. They move. Some can be derived from where the form sits or when it was submitted. Some are for the team rather than the respondent, and belong recorded against the response after it arrives rather than asked up front. Some can be asked in the first reply, where a person who has already made contact answers a direct question at no cost to the completion rate. A tool that can hold the response, the owner and the team's own notes together makes the third option practical, which is the point of the features page rather than any marking option in it.
What to change first
Count the asterisks on the longest form in use. If most fields carry one, switch to marking the optional fields with the word Optional and put a single sentence above the form for the rest, then check that every field with a marker also has the required attribute in the markup. If a field is required and nobody can say what breaks without it, take it off the list instead, and Halict shows the same form with required and optional set per question.
Q1. Should required or optional fields be marked?
Mark whichever set is smaller. On a form where nearly everything is required, marking the optional fields with the word Optional removes a screen of asterisks and reads as permission rather than demand. On a form where almost nothing is required, mark the few that are.
Q2. Is an asterisk enough on its own?
Only with a key nearby, and even then it is weaker than plain text. How a screen reader announces a bare asterisk varies, and a legend at the top of a long form has scrolled away by the time it is needed. The word Required or Optional needs no explanation anywhere.
Q3. Does the required attribute replace the visual marker?
No. They do different jobs. The attribute blocks submission and tells assistive technology what is expected; the visual marker tells a sighted visitor before they start. Generating the visual marker from the attribute using the :required pseudo class is what keeps the two from disagreeing.
Q4. Can colour alone show which fields are required?
No. Colour conveys nothing to a screen reader, nothing in a printed copy, and nothing to anyone who cannot distinguish the hue. Guidance on required fields is explicit that the treatment must not rely solely on colour, and that descriptive text or an icon is the usual answer. Colour alongside text is fine.
Q5. What about a login form, where both fields are required?
Leave the markers off. A marker exists to flag an exception, and on a sign in form there is no exception to flag. The required attribute still belongs on both inputs so the browser and assistive technology know what is expected.
Q6. What is aria-required for if the required attribute exists?
It covers controls that are not real form elements, such as a div given a checkbox role. It carries the same meaning to assistive technology but changes no behaviour, so a custom control still needs JavaScript to block submission and report the error. A real input with the required attribute is the better option wherever it is possible.