Online forms must be coded properly in order to be accessible. There a wide variety of issues that must be considered, and the form must be created with care.
Using the <label> element
Consider the following field, and the prompt that precedes it:
<div> Last name: <input type="text" name="last_name" id="last_name"> </div>
The prompt “Last name” precedes the input field, but its relationship to the field is not explicitly defined. Therefore, some screen readers will simply announce this as an “edit” field, but will not prompt the user to enter “Last name” into that field. Other screen readers will guess at the label, and in this example will probably guess accurately. However, as forms grow in complexity, screen readers that guess at labels are more likely to guess incorrectly, which means users are more likely to complete the form incorrectly.
The following code has been corrected. “Last name” is now defined as a label, and is explicitly associated with the form field because the label’s for attribute and the input’s id attribute share the same value.
<div> <label for="last_name">Last name:</label> <input type="text" name="last_name" id="last_name"> </div>
Providing supplemental help text
Only one <label> element is allowed per form field. However, if additional help text is available, it can be associated with the form field using the aria-describedby attribute. Screen readers will announce both the label and help text when the form field has focus.
<label for="DOB">Date of birth:</label> <input type="text" name="birthdate" id="DOB" aria-describedby="DOB-help"> <span id="DOB-help">MM/DD/YYYY</span>
Using <fieldset> and <legend> elements
For groups of related fields such as radio buttons and checkboxes, each form field must have a label as described in the previous section. However, that prompt alone can be meaningless if the user doesn’t know the question. The technique for addressing this problem is to group these elements together using a <fieldset> element, then use a <legend> element to markup the question, as in the following example:
<fieldset>
<legend>What is your favorite color?</legend>
<div>
<input type="radio" name="color" value="Red" id="color_red">
<label for="color_red">Red</label>
</div>
<div>
<input type="radio" name="color" value="Green" id="color_green">
<label for="color_green">Green</label>
</div>
<div>
<input type="radio" name="color" value="Blue" id="color_blue">
<label for="color_blue">Blue</label>
</div>
</fieldset>
Additional examples of form controls are available on WebAIM’s article Creating Accessible Forms.
Avoiding CAPTCHA
CAPTCHA (an acronym that stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”) is a type of form field that is sometimes used to determine whether a user is human, in an effort to prevent computers from automatically submitting online forms. Often CAPTCHAs assume the form of distorted characters such as those shown in the image below.
CAPTCHA is inaccessible to many groups of users, including people who are blind or dyslexic. If audio CAPTCHA is provided as an alternative for these users, that still is not a solution for people who are deaf-blind. Also, CAPTCHAs are burdensome for everyone and increase the likelihood that people will fail to submit the form or complete the task.
Google reCAPTCHA, starting with version 3, moved in a promising new direction as it operates behind the scenes and doesn’t burden the user. However, if it fails to recognize a user as human it defers to the content provider to provide some means of handling that user, which could result in inaccessible CAPTCHAs being used as a secondary test. The W3C maintains an extensive working group note on Inaccessibility of CAPTCHA, which describes a wide variety of alternative solutions.
Form validation
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 HTML 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 of 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 HTML 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:
- HTML5 Form Validation by Ian Oxley, on sitepoint.com
- Client-Side Form Validation with HTML5 by Collins Agbonghama, on sitepoint.com
Ensure client-side error handling is 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 container immediately after the form field and include the attribute 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 error handling is 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.
Get help
Given the critical roles forms often play in higher education, and the complexity of ensuring they’re accessible, please reach out to UW-IT Accessible Technology Services if you would like a review of your form. We can check for common problems and test with assistive technologies. See our Help page for more information.