Accessible forms are essential for creating an inclusive digital experience, ensuring that all users—including those with disabilities—can easily complete and submit information. Well-designed forms improve usability, making it easier for individuals to navigate fields, understand labels, and avoid errors.
Beyond enhancing user functionality, accessible forms are also a key requirement for compliance with regulations such as the European Accessibility Act (EAA), the Americans with Disabilities Act (ADA), and the Web Content Accessibility Guidelines (WCAG). Organizations that fail to meet these standards risk legal consequences, reputational damage, and lost business opportunities. By prioritizing accessibility in form design, businesses can improve user engagement, expand their audience, and demonstrate a commitment to digital inclusivity.
How accessible web forms (or inaccessible web forms) can affect your daily life
Last month, I was booking a rental car for a trip. Simple task, I thought. I picked my dates, chose a car, and got to the driver details page. I filled everything in, hit Continue, and got bounced back with a vague banner at the top of the page: “Please correct the errors below.” No errors were visibly marked. I scrolled up and down twice before I noticed my zip code field had quietly turned a faint shade of pink.
There was no indication that the field was required. No indication before I started, no flag when I skipped it. The only clue was a barely-there color shift that I almost missed—and I have great eyesight and was under no time pressure. At that moment, I realized again how much is often taken for granted when forms are designed.
If a color hint was subtle enough that it escaped me, imagine the situation for a screen-reader user, someone with low vision, or anyone who was just trying to get through the form quickly on their phone!
Methods for indicating a required field
These six methods run the gamut from ideal to “make sure to combine this with another method” to “please don’t do this.” Let’s start with a method that is very reliable, if not particularly elegant.
Provide the required text in the label
For this method, users of assistive technology (and users who don’t!) will know which form control is required because it is exposed through the label. It involves simply putting the word “required” right in the visible label text.
Syntaxe
<label for="fname">First Name Required</label> <input type="text" name="first-name" id="fname">
Aperçu
Because the word lives inside the label, every user gets it, whether they’re using a screen reader or not. There’s no dependency on symbols, color, or verbosity settings. It’s not the prettiest option—which probably explains why designers keep searching out other approaches—but it’s very reliable.
Provide an asterisk
The asterisk is still the industry default, and it’s an acceptable approach, as long as you handle two details that often get skipped.
First, tell users up front, before the form starts, that fields marked with an asterisk are required. Second, know that screen readers don’t always announce the “*” symbol; it depends on the user’s punctuation verbosity setting. If users have it set to announce “some” or “none” punctuation, your asterisk will silently disappear for them.
Syntaxe
<p>All fields marked with (*) are required</p>
<label for="first-name">First Name *</label>
<input type="text" id="first-name" name="first-name">
Aperçu
Tous les champs marqués d'un * sont obligatoires
Because of that verbosity issue, you should treat the asterisk as a visual convenience, and not as your only accessibility mechanism. For example, you can pair it with something programmatic (see method 4). Also, make sure the asterisk is visually large enough to be seen; default browser rendering is often too small to register at a glance.
Provide a graphic asterisk with real alt text
Some design systems prefer a small icon over a plain character. That’s fine too, as long as the image carries meaningful alt text rather than being decorative.
Syntaxe
<label for="fname"> First Name <img src="required-icon.svg" alt="required"></label>
<input type="text" name="first-name" id="fname">
This works well, because the label and the image are still programmatically tied to the input.
Définition des attributs obligatoires HTML5 et ARIA
This is where markup earns its keep. Add the HTML5 required attribute, or aria-required=”true” for custom or scripted controls, and assistive technology will announce the field as required automatically.
Syntaxe
<label for="email">Email</label>
<input type="email" id="email" name="email" required>
Aperçu
One thing worth knowing: when required is present, most screen readers will also announce the field as “invalid” until it’s filled in. That’s expected behavior, not a bug, but it does mean you shouldn’t rely on this attribute alone without including a visible cue as well. Sighted users still need to see it, not just have it announced.
Provide color alone (this is the one to retire!)
This approach is still prevalent (using color alone to indicate when a field is empty or required), and it’s still a problem. It fails outright for colorblind users, low-vision users, and anyone with a cognitive disability who needs more than a subtle hue shift to register meaning.
My rental car experience that I shared above is a perfect example. If color is part of your visual language, you can certainly keep it, but it should never be the only signal. Pair it with text, an icon, or both.
What’s new since we last wrote about required form fields
Here are a few things to consider as you’re thinking about required form fields in 2026:
Redundant entry is now a WCAG 2.2 success criterion. If you already know someone’s shipping address from a previous step, don’t force them to retype it into a “required” field further down the form. This isn’t strictly about labeling required fields, but it’s very much in the same spirit—don’t make required fields harder to satisfy than they need to be.
Inline validation is everywhere (and it’s easy to make it worse rather than better). AI-assisted, real-time validation that catches typos and flags missing fields as people type is a genuine trend in form design right now. Done well, it can help everyone finish faster. But when it’s too aggressive, it interrupts screen-reader users with error announcements before they’ve even finished typing. The better approach is to:
- validate on blur (not on every keystroke),
- pair the error with aria-invalid=”true” and aria-describedby pointing at the message, and
- offer a summary of all errors at the top of the submission.
Required-field errors should read like “Email address is required,” never “Invalid input.”
Regulators are paying closer attention. EN 301 549, the technical standard for the EAA, still points to WCAG 2.1 AA as its floor. However, WCAG 2.2 is increasingly treated as the practical target, and enforcement bodies across the EU are actively building out audit and complaint processes this year. If your forms are still relying on color alone or unlabeled asterisks, now is the time to fix it, so you can stay ahead of regulatory scrutiny.
Getting required form fields right
Building accessible forms is ultimately pretty straightforward. Tell people which fields are required before they start, not after they fail. Communicate this with words somewhere, not just with color or a symbol. Back this up with required or aria-required attributes so assistive technology also gets the message. And when someone does miss a field, communicate clearly what went wrong and where.
A required form field may be a small piece of a larger form, but it’s also often the difference between someone completing their task and someone giving up and going elsewhere. In my situation with the car rental company, I did find the pink zip code field eventually, but not everyone would have. In that case, it’s quite likely they would have taken their rental car booking to a competitor without so much as a second thought.
Getting required form fields right can make all the difference when it comes to meeting compliance requirements and ensuring your products, services, and experiences are accessible to everyone, including people with disabilities.
If you have questions about accessible forms or want expert guidance on meeting consumer and compliance expectations, contact Deque today!
