All WCAG rules
WCAG 3.3.2Level AWarningForms

How to fix: Required fields without visible indicator

When a field is required, say so in its visible label, with an asterisk (paired with a legend) or the word "required", and back it with the required or aria-required attribute, so the obligation is both seen and announced.

What it is

WCAG Success Criterion 3.3.2 Labels or Instructions requires that when user input is needed, the form provides the instructions to supply it correctly, and which fields are mandatory is exactly that kind of instruction. If a field will reject an empty submission, users need to know that before they submit, not after they hit an error.

The required HTML attribute makes a field mandatory for the browser and is announced by most screen readers, but on its own it gives sighted users no visible cue. The common gap is a field that carries required (so the browser enforces it) whose visible label still reads like an optional field, with no asterisk and no "required" wording. The obligation is enforced and announced but never shown, so sighted users discover it only when validation fails.

The fix is to make the requirement visible in the label text. The familiar convention is an asterisk next to the label paired with a one-time legend such as "* indicates a required field", or simply adding the word "required" to the label. Pair that visible cue with the required (or aria-required="true") attribute so the same fact is exposed to assistive technology, giving every user the instruction up front.

Who it affects & why it matters

Sighted users, including people with cognitive or attention-related disabilities, are the group this rule protects most: without a visible marker they cannot tell a mandatory field from an optional one until they submit and get bounced back by an error, which is frustrating and easy to abandon on a long form.

It works alongside the programmatic signal that screen reader and voice-control users rely on. The strongest approach satisfies both: a visible indicator in the label for people who see the form, and the required or aria-required attribute so assistive technology announces the same obligation, so no group is left guessing.

Missing required-field instructions fall under SC 3.3.2 Labels or Instructions, a Level A criterion, and clear input instructions are a standard finding in any serious accessibility audit. WCAG 2.1 Level AA, which contains all Level A criteria, is the benchmark U.S. courts apply to ADA Title III claims, so an undocumented mandatory field on a public form is a legitimate audit and demand-letter item.

The practical payoff is higher form completion. Forms are where sign-ups, checkouts, and leads happen, and telling people which fields are mandatory before they submit reduces errors, resubmissions, and abandonment for everyone. With accessibility lawsuits rising year over year and most targeting businesses under $25 million in revenue, and the WebAIM Million repeatedly flagging weak form practices, marking required fields is a small change with an outsized usability return.

How to fix it

  1. List the fields that carry the required attribute and check whether each one's associated label signals that it is mandatory.
  2. Mark the requirement in the visible label, either with an asterisk (*) or by adding the word "required" to the label text.
  3. If you use an asterisk, add a one-time legend near the top of the form, such as "* indicates a required field", so the symbol is explained.
  4. Pair the visible cue with the required attribute (or aria-required="true") so the obligation is announced to assistive technology as well as shown.
  5. Keep the indicator part of the field's real label so it is programmatically associated, not just floating nearby text.
  6. Re-scan to confirm each required field's label now contains an asterisk or the word "required".
Before
<label for="email">Email</label>
<input type="email" id="email" required>
After
<p>Fields marked * are required.</p>
<label for="email">Email *</label>
<input type="email" id="email" required aria-required="true">

How AccessKnight detects this

AccessKnight finds every element carrying the required attribute and locates its associated label, a <label for="id"> matching the field's id, or a <label> ancestor wrapping it. When a required element does have an associated label, AccessKnight reads the label's trimmed text and flags the field if that text contains neither an asterisk ("*") nor the word "required" (case-insensitive). In other words, it checks specifically that a required field's visible label communicates the requirement; required fields whose label already includes a marker pass this rule.

Frequently asked questions

Is a missing required indicator a Level A or AA issue?

It falls under WCAG 2.1 Success Criterion 3.3.2 Labels or Instructions, which is Level A. AccessKnight reports it as a warning-severity item, because the field is still functional but users are not told it is mandatory until they hit a validation error.

Isn't the required attribute enough on its own?

Not for everyone. The required attribute makes the field mandatory and is announced by most screen readers, but it shows nothing visually. Sighted users, including people with cognitive disabilities, need a visible cue in the label, an asterisk or the word "required", so pair the visible indicator with the attribute.

Do I have to use an asterisk?

No. An asterisk is the familiar convention, but the word "required" in the label works just as well and is arguably clearer. AccessKnight passes a required field whose label contains either an asterisk or the word "required". If you use an asterisk, add a legend explaining what it means.

Should I also add aria-required?

Use the native required attribute when you can, since it both enforces and announces the requirement. Add aria-required="true" when you need to signal the obligation on a custom control that cannot use native required, or to be explicit. Either way, keep the visible indicator in the label so the requirement is both seen and announced.

Is this issue on your site?

AccessKnight scans any page against all 30 WCAG 2.1 rules — including this one — and shows every instance with a fix. Free, no credit card.

Scan my site free →

More WCAG fixes