anatomy of accessible forms: required form fields, a form with a required label

The Anatomy of Accessible Forms: Required Form Fields

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

  • Provide the required text in the label.
  • Provide a graphic * image in the label with appropriate alt text.
  • Providing a star (asterisk) symbol.
  • Use of color to identify if a form control is required.
  • Providing HTML5 and ARIA required attributes.

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.

Conclusion

Now that we have seen multiple ways of providing an accessible mechanism to identify the required field, let’s see which method works best for all users.

  • If possible, provide an asterisk (*) in the label with appropriate alt text as required.
  • If an asterisk symbol is being used, be sure to also use HTML5 or ARIA required attributes on the form fields.

Filling out a form should be simple. With these couple of best practices in mind, forms can be both accessible and inclusive. Please let us know in the comments section which method works best for you and if there are any other methods we missed in this post.

photo of Raghavendra Satish Peri

About Raghavendra Satish Peri

Raghavendra Satish Peri is a digital accessibility evangelist working at Deque Systems as Product Manager [Accessibility] breaking web accessibility & mobile accessibility challenges.

He authors an Accessibility Blog & is galvanizing the adoption of accessibility by inspiring the local tech community with meetups and mentorship. When away from his computer, Raghava can be found at local cafes & restaurants sampling cuisines, attending local meetups, listening to audio books or writing on his Personal Blog.
update selasa

Comments 16 responses

  1. 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!

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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,

  9. 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?

  10. 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!

  11. 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?

  12. The aria required field symbol must be in “RED color” or any color can be used? Thanks

  13. 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?

  14. 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?

  15. 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.

Comments are closed.