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.



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.


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.



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.



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.



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.


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.

update selasa

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

Leave a Reply

Your email address will not be published. Required fields are marked *