The Anatomy of Accessible Forms: Required Form Fields
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 like 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!) Affect Our Daily Lives
Recently, I tried to order a cupcake on a new website and I utterly failed. I selected my choice of cake, added it to cart, tried to fill my delivery address and there started the road to chaos.
When I filled the details and submitted the form, a message saying “Please fill Address line 2” arose. Somehow, I sailed through and went to the “payment” section. Every time I clicked “submit,” it gave the same message: “please fill in the required field.” I scanned the forms to see if they gave any clue identifying these mandatory fields, but this effort was in vain.
Then, someone told me that the fields that were required would show in red color if they weren’t completed. If a person without disabilities couldn’t grasp these simple things while filling forms, I could imagine how people with visual, physical, and cognitive disabilities would feel.
Websites and mobile apps collect a wide variety of data using the forms. Most of these forms have required fields which means the user must fill these fields in order to submit the form successfully. There are multiple ways of providing this cue that a particular form field is required. Below, we will explore each of the methods.
This is the second blog post of my series on accessible forms, feel free to check out the first post in our series on placeholders.
How to indicate a required field
Clearly indicating a required field improves form usability, helps users complete forms accurately, and ensures compliance with accessibility standards like EAA. To do so:
- Provide the required text in the label.
- Provide a graphic * image in the label with appropriate alt text.
To indicate a required field, use a star (asterisk) symbol, incorporate color to visually identify required form controls, include HTML5 and ARIA required attributes, and provide clear “Required” text within the label.
Providing the Required Text in the Label
This method is one of the oldest techniques, the text required is provided within the visible label. For this method, both users who use assistive technology and non-assistive technology users will know which form control is required because it is exposed through the label.
Syntax
<label for="fname">First Name Required</label> <input type="text" name="first-name" id="fname">
Preview
Since the required text is part of the label, it is always visible and assistive technologies will expose it to screen readers if the form controls are programmatically associated.
Provide a Graphic * Image in the Label with Appropriate Alt Text
Sometimes, the described method above is not appealing to some designers. Some prefer to provide an image which conveys visually that the particular form control is required. For example, if the image is provided with appropriate alt text and the form controls are programmatically associated then the image, this method is accessible to assistive technologies.
Syntax
<label for="fname"> First Name <img src="example.jpeg" alt="required"></label> <input type="text" name="first-name" id="fname">
Providing Star (Asterisk) Symbol
This is one of the most widely-adopted methods to notify the users that a form control is required. A star (asterisk) symbol is provided along with the label. If the label is programmatically associated with form control, then it is accessible to assistive technologies. For screen readers to expose the “*” symbol, the punctuation settings should be set to most. Sometimes, if the punctuation is set to some or none, then screen readers ignore the special symbols.
While all screen reader users might not know how to set the verbosity settings, it is best practice to use this method in conjunction with another available method as a fallback. Users must be notified that all fields marked with asterisks are required before the form, since the default asterisks symbol is small in size it should be made large enough so that all users can perceive it.
Syntax
<p>All fields marked with * are required</p> <label for="first-name">First Name *</label> <input type="text" id="first-name" name="first-name">,
Preview
All fields marked with * are required
Use Of Color to Identify if a Form Control is Required
Often designers use color as a method to identify if a form control is required. When a user moves into the form field or moves out of the form field, the form control changes to a red color. This method is not recommended as it is not accessible for users with low vision, colorblind users, users with cognitive disabilities, and users with visual disabilities. This method can be implemented if there is an alternative fallback method that is “a visual cue,” which can help all users identify if the form control is a required field.
Providing HTML5 and ARIA Required Attributes
The “required” attribute was introduced in HTML5. If this attribute is used on any form field, it is identified as required by assistive technologies. Please note that when a required attribute is used on a form control screen reader announces that field is required and also invalid. Once the form field is filled, the “invalid” notification will not be announced to screen reader.
Syntax
<label for="first-name1">First Name</label> <input type="text" id="first-name1" name="first-name" required>
Preview
Similar to the“required” attribute in HTML5, WAI-ARIA introduced the “aria-required” attribute. If this attribute is used on a form control it will be exposed as required by assistive technologies.
Syntax
<label for="first-name2">First Name</label> <input type="text" id="first-name2" name="first-name" aria-required="true">
Preview
While the HTML5 and ARIA required attributes help assistive technology users, there should be a mechanism for sighted users to identify the required form controls through a visual cue like an asterisk (*) or a graphic. Some assistive technologies and browsers might not support these attributes, so it is a best practice to also have a fallback option.
Accessible Web Forms and EAA Compliance
The European Accessibility Act (EAA), effective June 28, 2025, mandates that products and services within the EU meet specific accessibility standards. While the EAA does not explicitly detail requirements for form fields, it references the harmonized standard EN 301 549, which incorporates the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.
These guidelines emphasize the importance of accessible forms, including clear identification of required fields, to ensure usability for individuals with disabilities. Therefore, to comply with the EAA, organizations should design forms that align with WCAG 2.1 Level AA criteria, ensuring all users can effectively interact with their digital content.
Turn to Deque for Help With Accessible Web Forms and Other Compliance Issues
Ensuring your forms are accessible is a critical step in creating an inclusive digital experience and meeting compliance requirements under regulations like the European Accessibility Act (EAA), ADA, and WCAG 2.1. By properly labeling required fields, using clear instructions, and implementing best practices in form design, you can improve usability for all users, including those with disabilities.
If you have questions about accessible forms or need expert guidance to meet compliance standards, Deque is here to help. Our accessibility experts provide the tools, strategies, and support needed to ensure your digital experiences are fully accessible and compliant. Contact us today to get started on your accessibility journey.
Do you have an opinion on marking fields as “optional” instead of “required.” I’ve also heard that advised and wondered if you feel one is more usable than the other (or what context one might be used over the other).
Excited for this series as I’m working on forms now!
Hi Jackie,
Yes it is a best practice & a good user experience if the optional fields can be marked-up as optional within the label. At the same time if you have marked-up the required fields with a visual indicator or required text in label then I don’t think we need to mark-up the optional fields. Users will understand from the hint provided “All form fields marked-up with * are required” & fill them accordingly.
Hope this answers your question.
I personally lean towards required, as it’s a paradigm that screenreader users are likely to have come across on other websites, whereas they mightn’t have encountered any forms with fields marked as optional.
Hi Isabel,
As a screen reader user myself I have seen in the wild, forms that mark the optional fields with text “option” in label. This is not something we see all the time & most of the time the word “optional” is used with “placeholder” attribute.
I just read another blog on deque that says the asterisks are not read at all or read as a star and so you need to use another backup method. https://www.deque.com/blog/dont-screen-readers-read-whats-screen-part-1-punctuation-typographic-symbols/
Has this changed? I am wondering what else you can do. Add an aria label to the asterisk itself?
Hi Susan,
Screen readers & assistive tech has evolved a lot & evolving very fast. I can confirm that NVDA & JAWS can read asterisk [* symbol] without a problem. I am on default settings on my screen reader.
Hope this helps.
Can you comment on how important this is when you are talking about a 2-field form, e.g. a sign in? If your two fields are Username and Password, is it necessary to indicate that these are both required? I don’t feel it’s necessary for users without disabilities.
I have seen in the wild, forms that mark the optional fields with text “option” in label. This is not something we see all the time & most of the time the word “optional” is used with “placeholder” attribute.
Hi,
Can I confirm that when using an * to highlight a required field the appropriate/expected position for this would be at the end of the field label – as per the above fields on this reply submission?
Thanks in advance,
Regarding placement of the asterisks for required fields, should the asterisks be placed in front of the label or after the label?…Does placement matter?
To Susan’s point in her message here:
“I just read another blog on deque that says the asterisks are not read at all or read as a star and so you need to use another backup method. https://www.deque.com/blog/dont-screen-readers-read-whats-screen-part-1-punctuation-typographic-symbols/
Has this changed? I am wondering what else you can do. Add an aria label to the asterisk itself?”
It is probably a good time to update that article, since the date on it was 2014, roughly 6 years ago and in many ways, no longer valid. I would love to see an update to that article in particular, to show how things have grown, and changed over the last 6 years when it comes to this subject.
I would also love to know best practices on error handling. I am updating a form page now to ensure it is compliant, and while I have found a lot of information on forms themselves, I have not found much in the way of best practices in error handling when mistakes are made, and what I’ve tried so far doesn’t seem logical.
Otherwise, fantastic article – thank you!
Great article! I am wondering whether using both an (accessible) asterisk in the label and also a required/aria-required attribute on the input would be considered unnecessary? I do understand that some browsers/and or screen readers don’t handle the HTML5 attributes perfectly, but that has to be pretty rare today. Wouldn’t hearing the same information repeated twice be annoying?
The aria required field symbol must be in “RED color” or any color can be used? Thanks
Thanks for the great article! In multi-step forms of government procedures where every field is required, do you believe it is still necessary to use the asterisk? Isn’t better just to indicate the optional fields in the very few cases they are present?
Hi there,
That was a nice article. I have few questions:
1) Consider form field and error messages: does all the error messages displayed in the form field should have ALERT Icon?
2) if there is a series of content and suppose there is a coupon code or referral code form field and error message appears do we require ALERT Icon for this error?
Color alone can not be used as means of conveying info but the error message is programmatically associated to the respective form fields.
Overall is ALERT icon required for error messages?
I’d be interested to know how many / what fields you’d recommend having on a form, and which ones should and shouldn’t be mandatory? Been pondering this for many years now.