How do people know a field must be filled in?
Most forms mark required fields with a red asterisk and hope people know the convention. Many do, and many don’t. A screen reader reads the asterisk as “star” or skips it, depending on its settings. People with colour blindness may not see the red. People new to the web, or using a translation tool, may not know what a star means at all. Each of them finds out only when the form refuses to send.
Two layers fix this. In the HTML, the required attribute tells the browser, and through it the screen reader, that the field must be filled in. On screen, a line of text explains the marker, or the label says “required” in words. WCAG 2.2 asks for both: 3.3.2 Labels or Instructions covers telling people what input is expected, 1.3.1 Info and Relationships covers putting that information in the code, and 1.4.1 Use of Color says colour must never be the only way to tell.
What does the required attribute do?
Adding required to an <input>, <select> or <textarea> does three things. The accessibility tree marks the field as required, so a screen reader says “Your name, edit text, required” when focus arrives. The browser’s own validation refuses to submit the form while the field is empty and shows a message near it. And CSS can style the field with the :required and :invalid pseudo-classes.
Look at the demo in the **Screen reader** view before and after. Before, the three lines end with “edit text”. After adding required, each ends with “required”. The optional words field stays as it was, which is how people can tell the difference without looking.
For a group of radio buttons, put required on at least one radio in the group; one is enough for the browser to require a choice. Checkboxes are separate: required on a checkbox means that box must be ticked, which suits “I agree to the terms” and nothing else.
<label for="phone">Phone <span class="req">*</span></label>
<input id="phone" type="tel" autocomplete="tel" required>
When should you use aria-required instead?
Use aria-required="true" only when the browser’s validation would get in the way and you need the announcement anyway, or on a custom control built from ARIA roles, such as a role="combobox" widget, that has no native required. It adds “required” to what the screen reader says and does nothing else: no validation, no blocked submit, no :required styling.
Never put both on the same field. The native attribute already sets the required state, so aria-required adds nothing but noise for anyone reading the code later. And put it on the field itself. On a <label>, as in the Break It page, it is ignored, because the label is not the thing being filled in. This follows the first rule of ARIA use: when a native attribute does the job, use it.
How should the asterisk be explained?
Pick one approach and use it on every form of the site. The first is an asterisk on each required label plus a sentence at the start of the form, “Fields marked * are required.” Put the sentence before the first field, so people read it before they need it. The second is the word “required” in each required label, or “optional” in each optional one. When most fields are required, marking the few optional ones is shorter and quieter, as the Break It fix does.
If you keep the asterisk, a screen reader will read it out as part of the label, and with required set it will also say “required”. Some teams hide the star from screen readers with aria-hidden="true" to avoid hearing both. Either way is acceptable. A sighted person must be able to learn its meaning from text on the page, and the meaning must be in the HTML too.
<p>Fields marked <span class="req">*</span> are required.</p>
<label for="cname">Your name <span class="req" aria-hidden="true">*</span></label>
<input id="cname" autocomplete="name" required>Is the browser’s own validation good enough?
It is a reasonable start. When someone submits a form with an empty required field, the browser stops, moves focus to the first problem and shows a short message such as “Please fill in this field.” Screen readers usually announce that message. It needs no code and works with the keyboard.
It also has limits. The message bubble disappears after a few seconds, its wording is set by the browser rather than by you, and it describes one field at a time. It may not meet 3.3.3 Error Suggestion when a format is wrong, and its look can’t be styled. Many teams turn it off with novalidate on the <form> and write their own messages, while keeping required on the fields so screen readers still announce the state. The next lesson shows how to write those messages so they are announced and linked to the right field.
Newer CSS helps either way. The :user-invalid pseudo-class only matches after someone has interacted with a field, so you can style empty required fields red after people leave them, instead of the moment the page loads.
What about the select menu with a default choice?
A <select> always has a value, the first option, so required on its own changes nothing: the browser sees a choice and lets the form through. To make a real choice required, start the list with an option whose value is empty, such as “Choose a type”. The browser then treats that as no answer, and the screen reader reads the empty option as the current value, which tells people they still need to choose.
Think before forcing a choice at all. If most people pick the same option, pre-selecting it saves effort for everyone, including people who find forms tiring.
How do you check required fields?
Read every field in the **Screen reader** view. Required ones should end with “required”; optional ones should not. Then look at the page without colour: switch your system to greyscale, or imagine the page printed in black and white. If you can still tell which fields are required, the text side works.
Finally, submit the form empty in a real browser. Focus should move to the first required field and a message should appear. If nothing happens, or the form sends anyway, the required attribute is missing or novalidate is set with no replacement validation.
What do AI tools tend to produce?
Generated forms often add a red * with a .required class and no required attribute, because the class looks like it does the job. Others add both required and aria-required="true", or put aria-required on a <div> wrapper. Look for the attribute on the field itself, look for a sentence that explains the marker, and check that colour isn’t the only signal.
Field notes
- A red asterisk alone does not tell everyone that a field is required.
- The
requiredattribute makes screen readers say required and stops empty submits. - Add a line of text that says what the asterisk means.
- Check each field in the Screen reader view to hear whether it says required.
Easy to get wrong
The star is decoration until the HTML says the field is required. Without required, screen readers don’t announce it and the browser doesn’t check it.
Instructions that depend on colour fail 1.4.1 Use of Color. People who can’t see red can’t follow them.
The native attribute already sets the required state. Doubling it adds nothing and suggests the code was copied without being understood.
A select with no empty option always has a value, so required can never fail. An empty first option makes a choice really required.
Questions people ask
Should I mark required fields or optional ones?
Whichever is rarer on the form. If most fields are required, label the optional ones with “(optional)”. If most are optional, mark the required ones. Say which approach you use at the top.
Does a screen reader read the asterisk?
Often, as “star” or “asterisk”, depending on the screen reader and its punctuation setting. Some skip it. That is why the required attribute and a text explanation matter more than the symbol.
Can I use the required attribute and still write my own messages?
Yes. Add novalidate to the form to stop the browser’s bubbles, keep required on the fields so screen readers announce them, and check the fields yourself on submit.
Is a required field the same as an error?
No. Required is a fact about the field before anyone types. An error appears after someone tries to submit something wrong. The next lesson covers marking and announcing errors.