Property Widget state

`aria-required`

Indicates that user input is required on a control before a form can be submitted. Use the HTML required attribute on native form fields; reach for aria-required only when no HTML equivalent exists — e.g. a combobox built on a div.

When to use

Only when the HTML required attribute is not available. Native form fields — <input>, <select>, <textarea> — should use required. The HTML attribute is announced by every screen reader, participates in browser form validation, and triggers the :required CSS pseudo-class. aria-required does none of that on its own; it is purely an announcement.

The legitimate cases for aria-required:

A custom role="combobox" built on a <div> or styled <input> where you’ve taken over validation.
A role="radiogroup" where the group as a whole is required (you cannot put required on a <div>).
A custom date picker, file picker, or rating widget that is not a native input.

If you can use HTML required instead, do.

How it behaves

Boolean. aria-required="true" makes the AT announce “required” (or “must fill in”, depending on the screen reader) alongside the field’s name and role. aria-required="false" is the same as omitting the attribute and is rarely needed.

aria-required does not prevent submission. It does not add a red asterisk. It does not toggle a CSS pseudo-class. It is purely a signal to AT. You still own the validation logic, the error messages, and the visible required-field marker.

The visible required marker (a *, the word “required”, etc.) should also be conveyed in the accessible name — either in the visible label text, or via a description — so a sighted user and an AT user get the same information.

Common failures

Using aria-required="true" on a native <input> instead of the HTML required attribute. Works, but you’ve thrown away the browser-validation and :required styling for no reason.
Setting aria-required="true" on a non-form-control — a button, a heading, a div with no role. The attribute is ignored.
Forgetting the visible required indicator. Sighted users see an unmarked field; AT users hear “required”. WCAG SC 1.3.3 problem.
Marking a field required in ARIA but skipping it in the actual form-submit validation logic. The announcement says required; the server happily accepts blanks.
Coupling aria-required with aria-invalid="true" too early. The field is invalid only after the user has tried to submit and left it blank, not at page load.
Localizing the visible ”*” marker but forgetting the screen-reader text in the label is now mismatched.

Example

<!-- Native input: prefer the HTML attribute -->
<label for="email">
  Email <span aria-hidden="true">*</span>
</label>
<input id="email" type="email" required aria-describedby="email-hint">
<p id="email-hint">Required. We will only use this to send your receipt.</p>

<!-- Custom combobox where HTML required isn't available -->
<div
  role="combobox"
  aria-required="true"
  aria-labelledby="country-label"
  aria-controls="country-listbox"
  aria-expanded="false"
>
  <input type="text" id="country-input">
</div>
<span id="country-label">Country (required)</span>