Anatomy of Accessible Forms: Errors of the ways

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

Form Validation & 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

• Anatomy of Accessible Forms! Placeholder is a Mirage
• Anatomy of creating accessible forms: Is this field ‘Required?’
• Anatomy of Creating Accessible Forms: Practice the best

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.