Tell screen readers a field is required
aria-required=true tells assistive technology that a field has to be filled in, and it gets announced with the field's name. W3C lists ARIA2 as advisory for every criterion it touches, structure, error identification and labels alike, so it improves a form and never satisfies a rule on its own. That is the right way to hold it, because the attribute is only half the job. All three of W3C's examples pair the attribute with a visible signal, an asterisk inside the label, the word required next to it, or a red border with a star. The third one is the case worth noticing, because a star drawn by CSS reaches nobody at all, and the attribute is what rescues it for one audience while sighted keyboard users still get nothing.
How we find it in an audit
The attribute itself is a mechanical check, and so is the modern equivalent, the required attribute on a native input. Neither tells us whether the form said so out loud, so we read the labels. A required field marked only by a red border, or only by a star drawn with a CSS pseudo-element, is the failure this technique exists next to.
How affected users experience it
Somebody fills in the fields that looked necessary, presses submit, and the form comes back with errors on three fields that gave no sign of being required. Now they are working backwards through a form they thought they had finished. With the requirement announced alongside the name, the decision happens once, at the field, which is where everybody else got to make it.
Passes vs. fails
Passes
<label for="email">Email (required)</label>
<input id="email" type="email" aria-required="true">Fails
<label for="email">Email *</label>
<input id="email" type="email">
<!-- the star is drawn by CSS and reaches nobody -->How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
- Error message describes invalid form field valueA tool finds candidates, you decide
The other techniques filed under this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as advisory for that rule rather than sufficient, which means it helps real readers without being accepted as evidence you conformed.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique ARIA2: Identifying a required field with the aria-required property. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.