Required fields (clear required + clear errors)

A short, practical UI accessibility note for games and web UIs. No tracking.

Try the micro-demo: required-fields-demo.html

It compares “asterisk/color-only required” (BAD) vs explicit required text + accessible error associations (BETTER).

What goes wrong

Asterisk-only: “*” without a legend is ambiguous. Some users don’t notice it, and some don’t know what it means.
Color-only required indicators: a red border or red label can be missed (color vision differences, dark mode, glare, low contrast).
Vague errors: “Something went wrong” doesn’t tell the user what to fix.
Unlinked errors: if error text isn’t connected to the field, screen readers may never announce it at the right time.

Checklist (minimal, safe)

Mark required fields with text, e.g. “(required)”.
Also mark optional fields with text, e.g. “(optional)”, to reduce uncertainty.
On submit, show an error summary near the top that names missing fields and links to them.
For each invalid field: set aria-invalid="true" and include the error element in aria-describedby.
Keep errors short: “Enter your email.” / “Choose a username (3–20 characters).”

Minimal field wiring (concept):

<label for="email">Email (required)</label>
<input id="email" type="email" required
       aria-describedby="emailHelp emailErr" aria-invalid="true" />
<div id="emailHelp">We’ll only use this for account recovery.</div>
<div id="emailErr">Enter your email.</div>

Tie help + error text to the field with aria-describedby. Only set aria-invalid when invalid.

Common pitfalls

Validating while typing: don’t nag. Prefer validating on blur or on submit (see: real-time validation note).
Only one error at a time: users may fix one field, submit, then get blocked again. Consider showing all errors after submit.
Moving focus unexpectedly: it’s okay to focus an error summary after a failed submit, but avoid focus jumps during typing.