✎ Technique: Required fields

Source: https://accessibility.huit.harvard.edu/technique-required-fields Parent: https://accessibility.huit.harvard.edu/creating-accessible-forms

A clear indication that specific form fields are required can save users time and avoid potential errors relating to missing data when a form is submitted.

This indication should be visually distinct without relying on color, and it should also be programmatically available to screen-reader users.

Examples

✗ Bad example

In this example, the asterisk is placed next to the text input. It has no connection to the input, so it will not be read aloud when the input is focused, and the screen-reader user would have no idea that it was required. If it were read, it would be read as “asterisk,” even though it should be read as “required.”

<label for="email">Your email</label>\ <input type="text" id="email" /> <span>*</span>

✗ Bad example

In this example, the asterisk is inside the label, so it is announced. However, “asterisk” or “star” does not clearly convey that the field is required.

<label for="email">Your email *</label>\ <input type="text" id="email" />

✓ Good example

In this example, the aria-required attribute is placed on the form field itself, meaning that “required” will be read when the control has focus. In addition, the redundant “star” is hidden from screen readers by placing it inside a <span> with aria-hidden="true". Content in a DOM tree with an aria-hidden="true" attribute is ignored by screen readers.

<label for="email">Your email <span aria-hidden="true">*</span></label>\ <input type="text" id="email" aria-required="true" />

This information is now available to screen readers whenever the field is focused. For example, VoiceOver (macOS) will read, “Your email, required, edit text.”