A sign-up form marks required fields with a red asterisk beside the label text. Which users does that leave out, and what makes "required" actually reach everyone?
answer
- a symbol nobody defined
- outside the label, outside the name
- colour is not a channel
- key goes before the form, not after
- invert it when most fields are mandatory
basics
~20 sA red asterisk carries the meaning in colour plus an unexplained symbol. It needs a visible key stating what the asterisk means, the marker inside the label's text so it travels with the field's name, and the required attribute so the control itself exposes the state.
solid answer
~60 sAn asterisk is a convention, not a definition, so three groups miss it. Users who do not know the convention have no way to learn it if nothing on the page says what `*` means. Users who cannot distinguish the red have only a small punctuation mark to go on. And a screen-reader user only encounters the marker at all if it sits **inside** the `<label>` element — an asterisk rendered in a separate element next to the label is not part of the field's name. So: put the marker in the label's text content, add a visible key before the form ("Fields marked * are required"), and put `required` on the control itself so the browser exposes the required state and enforces it, rather than relying on a visual marker alone. If the asterisk reads badly when announced, put the word in the label instead — "Email (required)" — which needs no key at all. And when nearly every field is mandatory, the honest inversion is to mark the *optional* ones.
code
html · 9 lines<p>Fields marked <span class="req">*</span> are required.</p>
<!-- Marker inside the label, and the state on the control itself -->
<label for="email">Email <span class="req">*</span></label>
<input type="email" id="email" name="email" required>
<!-- No convention to learn: the word is the marker -->
<label for="pwd">Password (required)</label>
<input type="password" id="pwd" name="pwd" required>go deeper
Know that a required field needs both a visible indication and the required attribute on the control, and that the visible marker belongs inside the label element rather than beside it.
Explain why the marker's position matters — text inside the label becomes part of the field's name — and why a symbol needs a stated key while colour cannot be the only difference.
Show judgment about the pattern itself: propose inverting to mark optional fields when most are mandatory, place the key before the fields, and keep the visual marker and the required attribute consistent.
Own required-field marking as a system-wide convention rather than a per-form choice, so every product surface states it the same way and teams do not relitigate asterisks in each design review.
## What an asterisk actually communicates Nothing, by itself. `*` is a learned convention that a large share of users know and a real share do not, and the page usually never states it. Compare that with a field whose label reads "Email (required)": no convention, no key, no colour, and nothing to learn. That comparison is the fastest way to see what the asterisk pattern is asking of the user. The pattern is not wrong — it is compact and widely recognised — but it only works when three things are in place. ## One: the marker must live inside the label ```html <!-- The asterisk is outside the label: not part of the field's name --> <label for="email">Email</label> <span class="req">*</span> <input type="email" id="email" required> <!-- The asterisk is inside the label: it travels with the name --> <label for="email">Email <span class="req">*</span></label> <input type="email" id="email" required> ``` The accessible name of a control comes from its label's text content. A marker placed in a sibling element is visually adjacent and semantically unrelated — it will not be encountered by someone moving through the form control by control. Putting the marker inside the label element is the single change that makes the visual pattern and the announced pattern agree. Be aware that how a bare `*` is announced varies — "star", "asterisk", or nothing at all, depending on the user's punctuation settings. That variability is precisely why the next two pieces matter. ## Two: the convention needs a key If you use a symbol, define it in visible text before the fields it applies to: ```html <p>Fields marked <span class="req">*</span> are required.</p> ``` Before, not after — a key at the bottom of the form is read after the user has already met every asterisk. This one line converts an assumed convention into stated information, and it costs nothing. The alternative that removes the problem instead of documenting it is to write the state as words in the label: "Email (required)". It is longer, it is unambiguous for everyone, and it needs no key. Many design systems visually hide the word and show only the asterisk, which keeps the compact look while putting real text in the name — a reasonable compromise as long as the visible asterisk still has its key. ## Three: colour is not a channel on its own If the asterisk is red and the optional-field markers are absent, then a user who cannot distinguish the red still sees the asterisk — that is fine, because the *shape* carries the meaning and colour merely emphasises it. The failure case is a design where colour is the **only** difference: red label text meaning required versus grey label text meaning optional, with no symbol or word. Then the information exists in exactly one channel that some users do not receive. The test to apply is simple: render the form in greyscale and ask whether required fields are still identifiable. ## Four: the control must carry the state A visual marker describes the field to people looking at it. Putting `required` on the control is what makes the *control* required — the browser exposes the required state to assistive technology and blocks submission of an empty value. Marker and attribute are not alternatives; ship both. A form with asterisks and no `required` attributes is decorated, not validated; a form with `required` and no visible marker makes users discover the rule by failing. ## Five: when almost everything is required If sixteen of eighteen fields are mandatory, asterisking sixteen of them is visual noise that trains users to ignore the marker. Invert it: state "All fields are required unless marked optional" and mark the two exceptions. Same information, a fraction of the marks, and the labels stay readable. This is the answer that tends to distinguish a senior response — the pattern is negotiable, the information is not. ## The answer in short "An asterisk is colour plus an undefined symbol. I'd put the marker inside the label so it becomes part of the field's name, add a visible key above the form explaining what it means, keep `required` on the control so the state is real and enforced, and if most fields are mandatory I'd mark the optional ones instead."
- Where exactly should the "* indicates a required field" key appear?In visible text before the first field it applies to. A key placed at the end of the form is encountered after the user has already met every asterisk, so it explains a convention they have already had to guess at. Putting it above the fields costs one line and turns an assumed convention into stated information.
- If the label already says "(required)", do you still need the required attribute on the input?Yes. The label text describes the field; `required` makes the control actually required — the browser exposes that state to assistive technology and refuses to submit an empty value. Label text alone is a promise nothing enforces. Keep both, and keep them consistent, because a label saying "required" on a control without the attribute is worse than either alone.
- Most of a long form's fields are mandatory. What do you do?Invert the marking. State "All fields are required unless marked optional" above the form and label only the exceptions. Marking fifteen of seventeen fields is noise that trains users to skip the marker entirely, and it clutters every label. The required attribute still goes on each mandatory control regardless of which way you mark them visually.
saying these in an interview costs you the question
- The red colour makes required fields obvious enough
- Everyone knows what an asterisk means
- aria-required on the input replaces the visible marker
- An asterisk beside the label is inside the label
- The required attribute alone tells users nothing is needed