Communicating error messages accessibly

Almost a year ago there was a discussion about accessible error messages in the WebAIM forums. Based on that discussion I take a look at how you can create accessible (and usable) error messages for your web applications.

Errors in web applications be divided into two groups:

  1. Server errors e.g. 404 Page not found and other HTTP protocol errors.
  2. Application errors e.g. The ‘Name’ field can not be empty. and other errors that your web based application will present to the user.

This article will deal with number 2: application errors. If you are more interested in server errors I suggest you have a look at The Perfect 404 by Ian Lloyd.

Proposal for accessible error messages

I propose the following requirements for error message presentation in web applications:

  1. Error messages should be accessible for as many users as possible regardless of culture, age and impairment.
  2. It should be easy to understand that an error has occurred.
  3. It should be clear what the user has to do to correct the error.
  4. It should be clear for the user where the error was found in the form.
  5. It should be possible to be notified about errors before submitting the form, especially if it is a complex form that takes time to process on the server.
  6. All errors should be displayed at the same time. No one wants to re-submit the form to find a new error.

I assume you already know how to create accessible forms and styling them properly so that sighted users can understand them. If you need more information about forms, please see the references at the end of this article.

Let’s see what we have to do to comply with the above requirements:

Visual presentation of errors

  • Make sure the user can see that an error has occurred. Error messages need to stand out from the rest of the layout. They should be placed at the top of the page if that is the area displayed after the form has been submitted with errors.
  • Use an error icon if your layout makes it difficult to visually separate errors from the rest of the page.
  • Be consistent when you present errors (the user will expect errors to be displayed at the same location and with the same style on all pages).
  • Update the page title to indicate that the user is on the same page but with errors (e.g. if the page title is “Registration” you could change it to “Registration – Error occurred”).

The error message text

  • Make sure the error message identifies the related field with the name as it is written in the label for that field.
  • Do not use complicated words. (tip: check out Ogdens basic english)
  • Describe what the user should do to correct the error, especially if it could be difficult to understand.
  • Make it clear if there were more than one error so that the user can correct all errors at once.

Markup of error messages

  • Make sure all user agents can parse error details. Use a heading to identify the error area.
  • Present each error as an item in a list. This makes it easy for the user to understand what has to be corrected. Also, screen reader users will find it easier to keep errors apart.
  • If you use software specific error id numbers (most developers do) do not hesitate to add them to the id-attribute of the li element. If you use automated functional tests (e.g. Rational Robot) it will be much easier for the test robot to parse and identify errors.
  • Provide an accesskey for the error message section. This is valuable if your form can generate many errors and enables the user to move back and forth between the error list and the form.
  • Make it possible to navigate from the error message to the related field. This makes it easier for users that navigate with the keyboard.

Client side validation

Using client side validation has many advantages. Users can get instant feedback instead of having to wait for a server roundtrip. Server load is also reduced. However, there are some things to take into consideration:

  • Never rely on client side validation alone. Only use it as a complement to server side validation.
  • Users must be able to submit the form and trigger server side validation even if client side validation failed. Some browsing devices (e.g. screen readers) will not understand that the page has been dynamically updated (with your error messages). This means that users will not understand why the form submission failed. One way of using client side validation is to trigger it when a field loses focus (on the onblur event).
  • Be careful when using the ASP.NET validation controls. By default ASP.NET will prevent form submission until the form is valid. For information on how to allow form submission with errors see Disabling Validation for ASP.NET Server Controls.

An example

Enough talking, let’s look at an example:

Error message sample

The markup for this sample error section with two errors looks like this:

<div id="validationerror">
  <h2 id="errorsummary">2 errors were found in your registration.</h2>
  <p>Please correct these errors and submit the form again:</p>
    <li id="er_128">
    <a href="#name" onclick="setfocus('name')">
    The Name field can not be empty.
    Please enter your name.</a></li>
    <li id="er_215">
    <a href="#age" onclick="setfocus('age')">
    The Age field can not be empty.
    Please enter your age in years.</a></li>

Clicking the validation error link triggers this simple javascript function:

function setfocus(objectid) { if(document.getElementById(objectid)) { document.getElementById(objectid).focus(); } }

Click here to see the complete validation error example. Evaluating the result can be done by looking at the personas from Mark Pilgrim’s excellent Dive into Accessibility. If you do not have access to a real test panel using personas is the next best thing.

Update: Reader Tanny O'Haley suggested that the label element should be used instead of setting focus with javascript. See details in comment 9 and 10 below.

I would be very happy for your comments and suggestions.


  1. Accessible form validation errors (WebAIM forum discussion).
  2. Disabling Validation for ASP.NET Server Controls.
  3. Client-Side Validation for ASP.NET Server Controls.
  4. IBM Accessibility center – Indicating required fields.
  5. Cross browser CSS :focus by Paul Griffin. Describes how you can use the focus pseudoclass in Internet Explorer (not used in the example in this article).
  6. AJAX and Accessibility.
  7. (about server errors) The Perfect 404 by Ian Lloyd.

Comments are closed.