Accessible Form Validation

9 min readJun 12, 2017

It is common for online forms to contain accessibility issues. This post will address 5 common form issues and provide suggestions to avoid them. Also check out my accessible form demo.

Common form issues:

Common form issue #1: Not providing a required field indicator as part of a field’s label

It is important to provide a required field indicator as part of a field’s label. For example, a common way required fields are indicated is to include an asterisk as part of the label. For example,

First name*:

Most screen readers will read this label as “First name star”. Historically, asterisks have been used as required field indicators for so long that users of assistive devices have learned that “star” means “required.” Another option is to include the word “required”:

First name (required):

A third option is for a developer to include the asterisk as an image, and provide an alt attribute for the image that is required:

<label for=”firstName”>First name<img src=”img/asterisk.gif” alt=”Required field” /></label>

This will appear to a sighted user like the first option above, but the screen reader will read the alternate text (“Required field”) instead of saying “star”. It’s slightly more usable than the first approach. Of course there are many ways of achieving this goal. The main rule is that when you test with an assistive device, the fact that a field is required should be stated.

A common approach that is not accessible is to make a statement at the top of a form that all fields are required. The problem with this approach is that the statement is generally marked up within a paragraph tag in the html. Content marked up as a paragraph will be bypassed by individuals tabbing through the site with their keyboard, so the text will never be read by a screen reader. Only links and form fields can have keyboard focus and be read by the screen reader.

This causes the irritating scenario in which an individual may leave certain form fields blank, thinking they are not required, but then will be unable to submit the form without understanding why. Often designers prefer to design forms this way because they prefer the aesthetic of form field labels without asterisks. I encourage designers to err on the side of a form being usable, because that is what a form is for. It is there to be filled out, so whatever can make it easier for them to fill it out is what we should do.

Don’t do this:

Common form issue #2: Not including explicit labels for each form input

Always include a label for a form field, even if it is not meant to be shown to a sighted user. A developer can ensure the label is included in the code.

Every form field needs an associated label. Associating a label with a field is helpful for sighted and non-sighted users. For sighted users, a descriptive label means a user can understand what information is needed within the field. A label will not disappear once a user clicks into the field, so it does not place a cognitive load on the user the way placeholder text would. The problems with placeholder text have been thoroughly outlined by the Nielsen Norman Group.

Don’t do this:

The case for search bars

In the case of a search bar, sighted users are familiar with the magnifying glass icon commonly used as a button. In this case, the convention is that the field does not need a visual label for a sighted user. However, it still needs a label for the screen reader to read, and that can be hidden with CSS. You can see a hidden label for the search bar implemented on this site. Note that this search bar also uses placeholder text. This will not represent an issue in this case because the word “Search” is always present next to the bar for sighted users, and a hidden label is available for non-sighted users to be read by an assistive device:

<label> <span class=”screen-reader-text”>Search for:</span> <input type=”search” class=”search-field” placeholder=”Search …” value=”” >

</label>

You can use the following CSS properties for hiding content from a sighted user, but still allowing access by a screen reader (from snook.ca):

position: absolute !important;

clip: rect(1px 1px 1px 1px); /* IE6, IE7 */

clip: rect(1px, 1px, 1px, 1px);

Common form issue #3: Not programmatically associating fields with labels

Now that I have convinced you to always include a label for a field, it is important to note from a development perspective how this is done. There are two ways to do it, depending on how you need it to appear. An example of how to programmatically associate a label with a field is shown in my accessible form demo.

(1) Wrap the label around the field:

<label>Search for: <input type=”search” class=”search-field” placeholder=”Search …” value=””></label>

(2) Programmatically associate the label with the field using the “for” and “id” attributes:

<label for=”search-bar”>Search for:</label
<input type=”search” class=”search-field” placeholder=”Search …” value=”” id=”search-bar”>
</label>

Common form issue #4: Not testing forms with a keyboard to make sure all functionality is clear

Once a form has been developed, try using it with your keyboard. First try simply tabbing through the form with your keyboard, and ensure that all of the following criteria are met.

You can see where the keyboard focus is on the form. There should be some kind of an outline around the field that is in focus to show you visually where you are. If your cursor gets lost, there is a problem.

You can tab through the form fields in an expected order. Focus should not jump randomly between the fields, and nothing should be skipped. For example, in a login form, the user should be able to tab through the username field, password field, forgot password link, and submit button. This seems obvious but many times the forgot password link is mistakenly placed outside of the flow of the form. The next figure shows the expected order for a user to tab through fields in an example form:

The cursor should never get trapped within a field. For example, if you will not let someone leave a form field until the format of the data passes a validation rule, that is not accessible. Let the user leave the field then return to it later if they need to.
No change to the form should occur on focus of a field. The change should only occur if the user hits the “enter” or “return” key. This type of issue used to occur more frequently when Javascript “Jump” menus were popular. In this scenario, a mouse user could select an item in a select menu simply by clicking it (as opposed to selecting it by clicking and then submitting their selection by clicking on a separate button). This is inaccessible, because in the equivalent keyboard functionality, a user would be forced to select the first item in the select menu, because the first item that received focus would automatically be selected and submitted.
Visible tooltips should also be read by the screen reader. This goes for any information on the form, including formatting information for a field. An easy way to do this is to include the formatting information within the field’s label so that it will automatically be read by a screen reader. See an example of an accessible tooltip in my accessible form demo

Fill out the form with intentional mistakes. When you try to submit the form, does the keyboard focus move to the first field with an error? Does an error message appear?

Then try the same exercise but without looking at the form. Use only your keyboard and a screen reader. See if the flow of the form makes sense, and the labels are descriptive enough, when you’re not looking at them. Again intentionally fill out the form with mistakes. Does your keyboard focus go to the first field with an issue on form submit, and is the error message read out by the screen reader? Read on for more details on how to make sure form validation is accessible.

Common form issue #5: Form validation that is not accessible

Form validation paradigms

There are two main paradigms for form validation, and one of them is more accessible than the other.

(1) Traditional form validation on submit, or “Reactive” form validation: In this scenario, a user can tab through form fields, filling them out, then hit the submit button at the end. At that point, the form will be validated, and error messages will appear on any fields that have issues. The user can try to submit the form at any time because the submit button is always enabled:
User can attempt to submit the form at any time, and the validation reacts to their submission:

This method of form validation is more accessible, because the user can receive instant feedback on any potential issues once they try to submit the form. When developed correctly, the first issue on the form will receive keyboard focus when the form is submitted.

(2) Modern form validation on tab out, or “proactive” validation: In this scenario, each form field is validated proactively as the user leaves the field, before they try to submit the form. Typically a visually highlighted error message will appear next to the field that has the issue. The submit button is not available (it is disabled) until all form fields are free of errors.

Some experiences disable the submit button until all fields are free of error:

This method of form validation is not accessible because once a user tabs out of field, they may not realize that they filled out the field incorrectly. A sighted user will see the error messaging, but a non-sighted user will not. Even worse, when the submit button is disabled, it cannot receive keyboard focus at all. The user will continue to tab and will never hear the word “submit”.

To use this strategy, it is more accessible to not disable the submit button. If absolutely necessary, the button can appear disabled through style properties, but a keyboard user should still be able to access it (it should still be able to receive focus).

Making error messages accessible

To ensure that non-sighted people using a screen reader can hear error messaging, it is important to programmatically append error messages to the field’s label on form submit. Here is how it should work:

User fills out form fields and tries to submit form.
The form is validated programmatically, and there are some issues that need to be resolved before the form is submitted.
Any field that has an associated error should have a descriptive error message appended to that field’s label.
Focus should then be placed on the top-most field in the form that has an error. The form field’s label and the error message should be read.

Here’s how this will feel to a user:

User fills out form, assumes everything is correct, and tries to submit the form. In reality, they have missed one of the fields (in this case, “First name”).
The form is validated with javascript, and it is determined that the first required field is missing information. The form submission is cancelled. An error message is appended to that field’s label.
Focus is also placed on that field’s label. By default, when a field has focus, a screen reader will read the label. The label will now be: “First name star, you must enter your first name.” See how the error message is now read along with the label?
Then they must tab through the rest of the form to get back to the submit button again. If there are any other fields with problems, error messages for those fields will also be read out with the field’s label, so the user will be made aware.
See this in practice on my accessible form demo.

Thanks for reading, and for caring about form accessibility. Leave a note in the comments if you have other ideas for making forms accessible.