Overview
Even if forms are coded properly for accessibility, users may make mistakes. They may inadvertently skip required fields, or enter invalid information. A well-designed online form provides helpful and timely feedback to users so they can easily correct errors and resubmit the form. When providing feedback to users, it’s important to ensure that feedback is accessible to screen reader users. The following techniques can all contribute toward accomplishing this.
Use Both Client-side and Server-side Validation
Client-side validation (using JavaScript) provides more immediate feedback, which can improve accessibility if implemented well. Server-side validation should be used as a fallback in case the user’s invalid submission slips through the cracks.
Avoid disabling the submit button. Some forms have disabled submit buttons that are enabled only after the form meets certain requirements. However, this can be very confusing for users if they discover they can’t submit but aren’t informed as to why. If you’ve provided them with client-side errors yet they’ve still reached the submit button without correcting the errors, let them submit the form, then reload the page and provide them with easy-to-discover errors on the new page.
Use HTML5 Attributes and Input Types
HTML5 includes a variety of new input types and attributes that will ultimately be very helpful for accessibility as browsers and assistive technologies build in support this new standard markup.
For example, the HTML5 required attribute can be used to identify required fields. When this attribute is present, screen readers inform the user that the field is required when the field receives focus. If users exit the field without entering anything or making a selection, the browser displays an immediate error which is fairly well supported by screen readers.
Also, HTML5 introduces several new input types (e.g., tel, url, email, date, time, color). Once fully supported, these will standardize form fields that have historically been added to web pages using widgets built with JavaScript, typically at the expense of accessibility. As standardized form fields provided by the browsers, users will encounter consistency across websites, and assistive technologies can more easily build in support for them. If browsers don’t support a particular input type, it is simply displayed as a text field.
Use HTML5 Validation Methods
One of the most powerful new features of HTML5 is its support for validation built into the HTML of the field. This is very easy to maintain with minimal code, and is highly accessible since the error messages come directly from the browser and are well-supported by screen readers. In addition to the required attribute described in the previous section, HTML5 also includes the pattern attribute, which can be used to define specific patterns of acceptable input for the given field using regular expressions. There are some very good articles online that provide additional details regarding HTML5 validation techniques. For example:
Ensure Client-side Errors are Accessible
If you are using JavaScript to do client-side validation and write errors to the screen, be sure to do so in a way that is accessible to screen reader users. For example, display errors in a container that includes the attribute role=”alert”. Screen readers support role=”alert” by interrupting users immediately when the content of that item changes, without the users’ losing their focus on the page.
Also, position the error immediately after the form field with tabindex=”0″, so if screen reader users don’t hear the alert, they are likely to discover it immediately after leaving the form field.
Ensure Server-side Errors are Accessible
If a submission fails server-side validation and the user is returned to the same page to correct the errors in their form, use these techniques to ensure that users are aware that there are errors and can easily find them:
- Change the <title> element of the page so it includes the word “Error”. Screen readers are likely to announce the title immediately when the page is loaded, so providing this information up front will make users aware that there are problems requiring their attention.
- Stylize the error message so it is visually prominent and easy to spot.
- Preface the error message with a high-level heading (preferably <h1>) that includes the word “Error” so users can jump directly to that message.
- Include clear, specific details in the error message, such as a list of the fields that have errors and the nature of those errors.
- Provide a same-page link that enables users to jump directly from each error message to the form field that requires correction.
Testing
Form fields should be manually tested by leaving required fields empty and entering erroneous data into fields that include validation. Be sure the error message make sense. If possible test using one or more screen readers to ensure the error messages are accessible.
External WCAG References
Most Details from this page were gleaned from the University of Washington's Accessible Technology section.