Understanding WCAG 2.0: 3.3.3 Error Suggestion

The next standard we’ll explore in our series on understanding WCAG 2.0 is 3.3.3 Error Suggestion. This standard is required for WCAG level AA compliance, which is part of what Section 508 requires. Here’s the complete text:

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 standard has to do with input validation. Let’s say that we have a webform, like this:

This standard is all about what happens when you enter the wrong thing. Say, for example, we enter “9740” as our zip code. This is the wrong way to tell the user:

Wrong

To meet this standard, all you need to do is provide a helpful error message:

Please make sure your zip code contains exactly five numbers, then resubmit the form

Of course, you don’t want go to the other extreme, either. Think about this nightmare:

Invalid Password. Your password must meet the following rules:

  • Not be more than 255 characters long
  • Contain at least one number
  • Contain a special character (!, @, #, $, %, ^, &, *)
  • Contain both an uppercase and a lower case letter
  • Not contain a space character
  • Be at least 8 characters long
  • Use only ASCII characters
  • Not contain your username or birth date
  • Not be written down on a note under your keyboard

One of the goals of this standard is to help people with cognitive disabilities. Yes, that error message explains all the possible circumstances that could have caused the error. But the suggestions aren’t helpful — you have to work to figure out which rule you violated.

And that’s it for this standard. If you’d like to avoid the the messy details, you’re welcome to just skip to the end. But this post got me thinking. When you’re making a form, labels are associated with form fields via the for attribute on the label and the id attribute on the field. That way a screen reader knows how to associate labels and form elements. But how does that work with an error message? There’s no for attribute for an error message. Right?

How to Associate an Error Message with a Form Element

The first place my research took me was the WebAIM site, which suggests a two part approach. First, error messages should be listed at the top of the form. Second, each error message should link to the associated input element. So our form would look like this:

Please make sure your zip code contains exactly five numbers, then resubmit the form

This method meets accessibility requirements, but fails from a usability perspective. If we were to expand that form to have several fields, then visually associating error messages and fields would be difficult. The best practice is to instead display the error message next to the form component it applies to, like Twitter does:

Screen shot of the Twitter sign up form, showing an error message next to an invalid phone numberBut that leads us back to linking the error message and the form component. WAI-ARIA provides a way to do that:

Please make sure your zip code contains exactly five numbers, then resubmit the form

I know that looks pretty much exactly the same, but I promise if you break out your developer tools, there’ll be some extra attributes. First, we need to add aria-invalid=true to the input (depending on your error, there are some additional attributes you can use). Then, we add the aria-describedby attribute to the input and have it point to the id on our error message.

If you’d like to know more about this method, check out this page on WAI-ARIA regarding form validation. Or, if you’d just like to know strictly what WCAG 2.0 requires, you can look at these examples and techniques. Specifically, be sure to check out the technique for using aria-required to indicate a required field – just putting a * next to each field isn’t good enough. This blog post provides some additional examples and advice.

Interested in more? Check out the listing of all the posts in this series.

2 thoughts on “Understanding WCAG 2.0: 3.3.3 Error Suggestion

  1. Looks good, but I do have 1 question?
    “Not be written down on a note under your keyboard?”
    Now do you know it is my PW under the keyboard?

    Just kidding that question has always bug me and you are the first person who would know or see the joke in it… Keep up the good stuff. David

    • Thanks for the encouragement! Believe it or not, we’re almost through all the posts. I forget when the last one is published, but certainly by mid next month we’ll be totally done. Then we just need to figure out how to get everyone trained and all the accessibility changes implemented.