Digital A11y

Required fields

Anatomy of Accessible Forms: Errors of the ways

Last Modified on by 2 Comments

“To err is human.” “To prevent, suggest and correct are divine.”

When we submit user data as in financial transactions, travel and entertainment bookings, or in filling surveys, it is quite common that we make mistakes. Let’s imagine we submit a form at the minimum of three times but we fail without knowing the reason for the failed form submission. Then one of our intelligent friend tells us to correct the fields that are marked in red. Even after correcting them, we couldn’t submit the form. Then another friend says to look for a tick mark in the date of birth that says that the date format is not correct. Even though we are familiar with these colors and visual cues, we wouldn’t expect them in all the places. Don’t we exclaim “Why can’t they just explain in words?” If this is a common experience for a common user, then I wonder about the frustrations of a person who is color blind, a person who is blind or low vision, a person who has limited cognitive abilities and who needs help in understanding these complex scenarios.

A form is never without error validation and an accessible form is never complete with accessible error identification.

 

Now that we understood a bit about placeholders, required fields & creating accessible forms using native HTML let’s look at the last leg of this journey “Form Validation & Error Identification”. If you have not taken a look at the other posts in this series we highly recommend that you start from the first one

 

WCAG2.0 specifies the following guidelines for Accessible form validation & error identification:

  1. SC 3.3.1 Error identification
  2. SC 3.3.3 Error suggestions
  3. SC 3.3.4 Error Prevention in legal and financial transactions

 

There are two methods of validating the forms, server side validation & client side validation. We will go through each method & see how each of them contributes to accessible experience for the users.

Server Side Validation

Server side validation means the data of the submitted form is sent to a web server & is validated on the server using scripts like PHP, JSP, Perl, etc. When a server side validation takes place the page that form contains refreshes & if there are any errors then the errors are displayed to the users. This is one of the oldest methods of validating forms.

 

If a server side validation takes place & user is sent to a page to identify & correct the errors, then use the following tips to notify users of the errors:

 

  • Change the title of the page- users including people with disabilities tend to check the page title when the page refreshes or when they are sent to a new page. Making sure that page title contains “Alert form has errors” will make sure that users know immediately that there are errors on page & form failed validation.
  • Give the error a heading level preferably a H1 so that assistive technology users can jump directly to the error & understand it.
  • Visually style the error in such a way that it is distinguishable from other content. This helps users with low vision & all user categories to identify the error easily…
  • Make sure that errors are clear & informative. Each error must specify which form field has the error & a short note on how to fix it.
  • Provide a same-page link so that users can jump directly to the form field that has the error.

 

Client Side Validation

 

Client side validation means the form validation is handled by browser using the Java Script. This type of validation provides instant feedback to the users during data entry into the form or once the form is submitted. Here the data is not sent to the server for validation.

There are multiple methods where errors are presented to the users in client side validation. But the concept of exposing the error & providing adequate feedback to the user to rectify that error remains the same.

 

Refer to the following points on how best to notify the users about errors in client side validation:

  • Present the errors   in text.
  • Make sure that errors are clear & informative so that users can fix the errors.
  • Don’t use visual cues like color or icons alone to identify the form fields that have the errors. If color or icons are used then provide the same information in alternative method so that it is accessible to all users.
  • Move the focus to the first form control that has the error or move the focus to the common error message.
  • Associate the inline errors with form fields by using aria-describedby attribute.
  • Provide appropriate suggestions, for example if email field is not valid instead of providing error message as invalid email provide “invalid email enter [email protected]”.

 

For a successful form submission, there are a lot of factors & we discussed each one of them in this series. While the WCAG2.0 provides guidelines to be compliant, the guidelines can go only so far. It is the duty of developers, designers & content authors to provide that unique & everlasting experience to users. Yes we can definitely say we are compliant with WCAG, but the question we need to ask ourselves is, are we providing that effortless experience & smooth transition? So don’t be just compliant go that extra mile to make your forms  accessible and usable.

 

 

We welcome your questions, suggestions & feedback. Please do let us know if you would like to see any more posts on any particular topic & we will address them in our future posts.

 

 

 

 

 

Continue reading Anatomy of Accessible Forms: Errors of the ways

Anatomy of Creating Accessible Forms: Practice the best

Last Modified on by Leave a Comment

When we complete a task independently and successfully, the exhilaration is boundless. Filling forms on websites and apps for people with disabilities and even for the non-disabled is such a task and the independence in that is exciting, even if it is simple.

The other day, I was amazed when I encountered such a scenario on a travel site. Even though I am an assistive technology user with limited motor ability and limited cognitive ability, I was able to fill in all the details on that travel site within five minutes! And guess what? Without any error! You know how?

It was all because, the forms had descriptive labels that were visible at all times; marking of mandatory fields that was accessible to everyone; never-vanishing instructions that were easy to follow; grouping of relevant form fields that clearly defined the purpose of those fields; minimal use of placeholders that gave the necessary hints and above all, proper communication of the role, name and state of the form controls to the assistive technology that I was using. I know it sounds utopian. But in imagination, it is real.

 

In our last two posts, we saw  the ill-effects of using the placeholder attribute & how to mark-up the required fields. If you have not taken a look at them then we recommend that you take a glance at these posts first & then come here.

  1. Anatomy of Accessible Forms! Placeholder is a Mirage
  2. Anatomy of Acccessible Forms! Required Form Fields

 

In today’s post we will go through all the ingredients of creating an accessible form that provides the best user experience for all the users. We will go through each aspect of creating an accessible form & understand why a particular step is important & how it affects people with disabilities or users in general.

 

Use Native HTML

The first rule to create a truly accessible form is to use native HTML form controls. They are accessible by default with all assistive technologies & it is semantically correct.

 

 

Let’s look at some examples of native form elements:

<input type=”text”>

<input type=”radio”>

<input type=”checkbox”>

<button>Submit</button>

Since we use the native HTML controls, the name, role & state of the elements are exposed by default to all assistive technologies. But if we are creating a custom control using WAI-ARIA techniques, all these need to be provided manually using various ARIA attributes like aria-label, aria-checked, role=”radio” etc.

 

Providing Visible Label

 

Now that we have talked about using the native HTML controls for the forms let’s dive into methods to make them accessible. The next step in the process is to provide visible labels for each form control. Without visible labels form controls are not usable to any user let alone a person with disability. A visible label is nothing but text that is in proximity to the form control that it is representing.

 

<b>First Name</b>

<input type=”text”>

<b>Terms & Conditions</b>

<input type=”checkbox”>

 

In the above example code, I have used bold tag to highlight the labels so that users can distinguish them easily. While we are at the subject of visible labels let’s recall  a bit about placeholder attribute. For some of input types we can use placeholder attribute but it is not same as providing visible label. The placeholder disappears once user inputs data into form control & we discussed the pitfalls of placeholder in the post “Placeholder is a Mirage”. So provide visible labels for all the form controls that you create.

 

 

Programmatic Labels

Now that we have understood why we need visible labels & started to provide them, we need to associate them programmatically to their form controls. Without programmatic association of the labels assistive technology users cannot identify the purpose of the form field. When a user focus moves into a text field it is read out as “edit field” without notifying the accessible name provided to it. To make sure that the visible accessible name is notified to the users we need to associate the visible label with form field.

<label for=”firstname”>First Name</label>

<input type=”text” id=”firstname”>

<label for=”lastname”>Last Name</label>

<input type=”text” id=”lastname”>

 

In the above example, we have used for & id method to associate the form field with its visible label. There are multiple ways to achieve the association but using the for & id method is native and is recommended.

 

Providing Descriptive Labels

Now that we have provided visible labels & associated them with their respective form fields the next step is to check if the form labels are descriptive enough. Will the user be able to read through the label & can take a necessary successful action? For example

<label>Name</label>

<input type=”text”>

<input type=”text”>

 

In the above example we can see that for both form fields the visible label is name but is it descriptive enough for the users to take necessary action? Simple answer is no! We already discussed that each form fieldshould contain it’s own visible label & it should be descriptive enough. In the above example the fix would be to provide visible labels for both form fields & specify where first name & last name should be entered.

<label for=”fname”>First Name</label>

<input type=”text” id=”fname”>

<label for=”lname”>Last Name</label>

<input type=”text” id=”lname”>

 

Grouping of Form Controls

 

Sometimes there will be a set of form controls that belong to a group& is provided with a group level visible label. The group level label conveys the necessary information to the users to take action. Let’s see this with an example

<p>Do you have a passport</p>

<input type=”radio” id=”yes”>

<label for=”yes”>Yes</label>

<input type=”radio” id=”no”>

<label for=”no”>No</label>

 

In the above example we can see that “do you have a passport” is the primary visible label for the set of radio buttons. But when assistive technology users navigate to these radio buttons using the tab key they miss on the key information of the primary visible label as it doesn’t get tab focus & the elements Yes & No when read-out by assistive technology doesn’t make sense. To help with this problem in HTML we have fieldset & legend attributes that will help us bind the group level form controls which will be announced to assistive technology users as expected. Now we will see the same example with fieldset & legend

<fieldset>

<legend>Do you have a passport</legend>

<input type=”radio” id=”yes1”>

<label for=”yes1”>Yes</label>

<input type=radio” id=”no1”>

<label for=”no1”>No</label>

</fieldset>

 

In the above example we can see that fieldset is binding the form controls inside a group & the legend attribute is used as the primary label that will be exposed when assistive technology user moves the focus to the first radio button either in tab or shift+tab navigation.

 

Providing Instructions

Some of the form fields need additional instructions to fill the data successfully & these instructions must be available to the users at all times like visible labels. We can bind the instruction to the form fields using aaria-descrivbedby attribute.

<label for=”dob”>Date of Birth</label>

<input type=”text” aria-described=”dob1” id=”dob”>

<span id=”dob1”>Use DD/MM/YY</span>

 

In the above example, the instruction is provided below the form field & is bound using aria-describedby to the text field. If the instruction is not bound to form fields then assistive technology users who only use tab key might miss on the key information. By using arrow keys too, users can get all the information but it is a better user experience if the instructions are associated.

 

To conclude, following all the best practices discussed above will create a form that is usable & accessible by all users. Native HTML is the key to create this unique user experience! if you want to build a custom control from ground-up because something is not available in HTML then we recommend using ARIA roles, states & properties. We will be discussing about creating custom controls in our upcoming blog posts & we did not touch base on the subject of validating the form & error identification as it will be the next post in series.

 

Continue reading Anatomy of Creating Accessible Forms: Practice the best

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

Last Modified on by 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..

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