Accessible Form Validation

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,

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

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:

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.

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.

  • 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

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.

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:

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

CPWA Certified Accessibility professional, front end development, technology leadership, user experience, random haiku poems.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store