Error messages: The good, the bad, and the terrible

One of my early memories of working in a web development company was an incident that happened with one of my colleagues over an error message (or lack of one).

I was making a couple of hurried Christmas purchases online during a lunch break. I’d just entered my details into an online form and my card number had been rejected.

“This field has errors” was the message. I checked the numbers and they were correct, but I entered them again anyway. I received an identical message. I had a good idea what had happened, but when I turned to my colleague and showed him the message, he laughed at me.

“You’ve put in the spaces!” he said.

To him it was obvious and once it was made clear to me I knew the spaces needed to be removed. It just so happens that an earlier purchase had gone the other way and I needed to add spaces. I wanted to make the point that it shouldn’t matter if I put spaces in or take them out. As long as the numbers are correct, it shouldn’t matter either way.

Since then I’ve always had a bit of a bee in my bonnet about error messages for forms. I’ve picked up some very simple points regarding error messages and form fields like the one I experienced:

  • Recent experiences influence current choices
  • A good way to lose a customer is to make them feel confused or stupid
  • Don’t over-validate; allow as much flexibility as possible

And last, but most importantly:

  • Provide informative error messages

Before we look deeper into examples of error messages, let us first ask what the WCAG guidelines to understand what is expected of forms and error messages.

Being accessible

The WCAG guidelines have the following criterion for errors on a page:

3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)

This means that there is an expectation that when forms have an error, there are useful suggestions that are given to the user in order to help them correct the form. Although the criterion itself doesn’t go into much detail, in the understanding section for this criterion, it does give examples of forms that contain specific data sets, such as choosing specific months from a calendar.

Of course, data security must be taken into consideration and where providing additional information could result in a person’s personal data being compromised, then this must not be given. An example of this could be when logging into a website. You may have seen an error that says ‘incorrect username or password’. The reason for this is that if the error text was ‘incorrect username’, the assumption could be that the password was correct, and a hacker may add this password to their list of potential passwords. This is not good for data security.

Let’s now look at examples of error messages, starting with a terrible example:

Terrible:

article error messages fig 1

This approach is truly awful, providing users with the least amount of information possible. The error message is generic, not just for the field, but for the entire form. With the fields being marked out in a colour, users need to be able to perceive colour to know which field has an error. This restricts users who are colour blind and people using screen readers.

We can imagine if there were several fields that might include address and credit card information, and the same error message is shown. I’m sure there are many questions that we or other users may ask. How many errors are they? How long will they take to correct? What is the correct format for a specific form field?

The lack of information can be frustrating to everyone, and may lead to individuals taking longer to complete a journey, or abandoning it altogether as they get frustrated.

Bad:

article error messages fig 2

The example here is still bad, although not as problematic as from the ‘terrible’ example. Rather than having a list at the top that says there are errors, we see an inline error being shown, where the error is located very close to the field to help identify the field as one that contains an error.

However, the description is still weak, simply saying that ‘the field has an error’. It doesn’t give any reason why this field may have an error. If this field were for another content type, such as a phone number, it could be that the user has inadvertently added letters or has included too many numbers to be a phone number.

It is also possible that the label is not programmatically associated to the field, meaning that although the form field and error message are visually next to each other, in the code it has not been ‘attached’ to a field through the aria-describedby attribute. This means that assistive technology users, such as screen reader users, will not have the error message conveyed to them. They may have no easy way to tell which of the fields have an error, and this may prevent them from completing the form altogether.

Best:

An example of a form with a good explanation of errors.

In the example above, there are errors positioned below the form fields with a clear text explanation of the issues for example, An or for an email field it must contain both the ‘@’ symbol and a suffix such as ‘.com’. If credit card details contain letters or an email doesn’t contain the ‘@’ symbol, we can easily detect the mistake in validation and provide a helpful and descriptive message.

There are some other things to consider:

If a field has been requires a certain type of input such as only numerical characters then this is covered under some of the new WCAG 2.1 criterion such as “Identify Input Purpose” which are designed to help a number of users complete forms correctly.

By including the input purpose of a field in the HTML code, it can help error prevention and helps a to be confident that they are entering correct information in to a field. This can be done by adding a  ‘type” attribute to the field. WCAG 2.1 section 7 provides examples of input purpose including ‘type=”email”‘ for email or ‘type=”cc-number”‘ for a credit card number.

When it comes to helping non-sighted users who are likely to be using text-to-speech software to read the age contents to them, it’s important that the error messages are read in addition to the field label. We can do this easily with the aria-describedby attribute.

In conclusion

Forms are an important part of websites, allowing companies to gather information on behalf of a user in order to provide goods or a service. I’m sure there have been times when all of us have entered details incorrectly into a form field, and we may have had times of frustration as we try to understand which details were added incorrectly. Making sure that your form fields are accessible to people with disabilities also helps make them much more user-friendly.

Testing form fields

It’s likely that your website has form fields, whether it be an email field for a newsletter or gathering large amounts of personal data in order to deliver goods and services to customers. If you are unsure whether any error messages on your forms meet accessibility guidelines, please feel free to contact Dig Inclusion, where we can test your forms and other parts of your website.