• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Logo for DigitalA11Y

Digital A11Y

Your Accessibility Partner

  • About
    • Bio
      • Conference Speaking
      • Videos
      • mentions
  • Articles
  • Resources
    • WAI-ARIA
    • WCAG
    • Cheat Sheets
    • A11Y Blogs
    • A11Y Toolkit
  • Contact
You are here: Home / Design / Anatomy of creating accessible forms: Is this field ‘Required?’

Anatomy of creating accessible forms: Is this field ‘Required?’

Last Modified: June 20, 2018 by Raghavendra Satish Peri Leave a Comment

If anyone asks me to vote on a day of frustration, I would vote for the day when I tried to order for a cup cake on a new site and I utterly failed. Well, 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, there came a message saying “Please fill Address line 2”. Somehow I sailed through and went to the “payment” section, it was a disaster. Every time I clicked “submit”, it threw the same message “please fill this field or that field”. I scanned the forms to see if they gave any clue in the first place for identifying these mandatory fields. But it went in vein.
Then, someone told that the fields that were required would show in red color if I didn’t fill. You dummy! I wondered aloud. If a person with all the abilities couldn’t grasp these simple things while filling forms, I could imagine how people with visual, physical and cognitive disabilities would feel.

Websites & Mobile Apps collect wide variety of data using the forms. Most of these forms have required fields which means 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 & we will explore each of the methods.

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 star (asterisk) symbol.
  • Use of color to identify if a form control is required.
  • Providing HTML5 & ARIA required attributes.

Providing The Required Text In The Label

This method is one of the oldest techniques where the text required is provided with in the visible label. This way both users who use assistive technology &non assistive technology users will know which form control is required as it is exposed through 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 & 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

Since the required text in the 1st method is not appealing from the design perspective some designers prefer to provide a image which conveys visually that this particular form control is required. If the image is provided with appropriate alt text example “required” & if the form controls are programmatically associated then the image along with it’s alternative text will be exposed 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 widely adopted methods to notify the users that a form control is required. A star (Astericks) symbol is provided along with the label & if the label is programmatically associated with form control then it is exposed to assistive technologies. For screen readers to expose the * symbol the punctuation settings should be set to most. Some times 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 vebocity settings it is best practice to use this method in conjunction with another available methods as fall back. Users must be notified that all fields marked with * astericcks are required before the form & since the default * 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

Some times designers tend to use color as one of the 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 turns into red color. This method is not recommended as it is not accessible for low vision users, cognitive users & visually challenged users. This method can be implemented if there is a alternative fall back method “a visual cue” that can help all users identify if the form control is a required field.

Providing HTML5 & ARIA Required Attributes

In HTML5 the “required” attribute is introduced. 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 & also invalid. Once the form field is filled then invalid 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


Similarly like “required” attribute in HTML5 WAI-ARIA introduced 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 HTML5 & 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 * or graphic. All assistive technologies & browsers might not support these attributes so it is a best practice to have a fall back option.

Conclusion

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

  • If possible Provide a graphic * image in the label with appropriate alt text as required.
  • If Providing star (asterisk) symbol is being used then make sure you also use HTML5 or ARIA required attributes on the form fields.

Filling a form would remain simple if the clues like these are accessible and inclusive.

Please let us know in the comments section which method works best for you & if there are any other methods we missed in this post..

Share A11Y Love

  • Twitter
  • LinkedIn
  • Facebook
  • Reddit

More Accessibility Articles

Filed Under: Design Tagged With: Accessible Forms, Form fields, Required fields

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 at DigitalA11Y.com & is galvanizing the adoption of accessibility by inspiring the local tech community with meetups and mentorship. He propelled this thought by founding HelloA11y.com, a community of accessibility professionals, developers and enthusiasts. 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 at raghava.in.

Reader Interactions

Leave a Reply Cancel reply

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

Primary Sidebar

Get Digital A11Y in Your Inbox

Recent A11Y Articles

  • WCAG 2.1 Checklist
  • A Sneak peek into WCAG 3.0 First Public Draft
  • Understanding SC 4.1.3 Status messages
  • Understanding SC 2.5.4 Motion Actuation
  • Understanding SC 2.5.3 Label in Name

Recent Comments

  • Donal Rice on Digital Accessibility Companies Roundup
  • Rajath on A Sneak peek into WCAG 3.0 First Public Draft
  • Raghavendra Satish Peri on Foresee Your Colors: Tools to Evaluate your design for Color contrast Accessibility
  • Raghavendra Satish Peri on Digital Accessibility Companies Roundup
  • Andrew Somers on Foresee Your Colors: Tools to Evaluate your design for Color contrast Accessibility

A11Y Categories

  • Design
  • Events
  • HTML
  • IOS
  • Mobile Accessibility
  • News
  • Tools
  • WAI-ARIA
  • WCAG
  • Web Accessibility

  • Privacy Policy
  • Sitemap
© 2021 Digital A11Y