Form Guidelines

Overview

Webforms require multiple different techniques to be made accessible. This should not dissuade you from using them; when implemented correctly webforms are the most accessible types of forms, specifically because they have multiple techniques available to make them more understandable to people with disabilities. The upfront effort required in making webforms might be more substantial than creating document-based forms, but tends to have lower maintenance costs in the long-term, so is encouraged whenever possible.

This article assumes you are using native HTML webforms. If you have access to third party services like Qualtrics, these services can be used to create accessible webforms, but they also have question options like drag-and-drop that are inaccessible, and the survey-creating interface itself is not accessible. External resources on accessible Qualtrics forms are available at the end of this article.

Guidelines

Add Instructions

All forms should have instructions at the start of the forms. These instructions detail what the form is, and how it is used.
If there are multiple input fields that all have the same formatting requirements, like 10 date fields that all use ISO formatting, it is appropriate to list this in an introductory instructions.
Simple forms like “Contact Us’ forms can make do with a single, brief description.
Complex multi-part forms with conditional questions may require extensive description. If there are a lot of instructions, consider providing a high-level description at the start of the form, and providing section-specific instructions before each relevant section.
If individual questions have specific formatting requirements, provide those in the input field labels.
- Placeholder text may be used, but it should supplement the always-visible instructions, it shouldn’t be the sole instruction on input requirements.

Required Fields

Required fields are commonly indicated with an asterisk (*).
- If so, there must be an instruction telling the user that * indicates required fields, before the first instance of the required field.

* Indicates a required field

Email: *

Using the required HTML attribute is recommended, but these attributes are not read by all screen readers, so it does replace the need for a visual required field.
Color cannot be the sole indicator of a required field. You may use a red asterisk to indicate a required field, but you can’t solely make the text of a required question red (and not use an asterisk) to indicate that it is mandatory.

Input Field Labels

All form fields must be labeled. Whenever possible, this should be done with the HTML <label> element instead of ARIA. The for attribute on the label points to the id of the <input> element.
The Email example above is written as follows:

<label for=”email”>Email: *</label>
<input type=”text” id=”email” required>

Radio buttons and grouped questions should be grouped within <fieldset> elements, with child <legend> tags surrounding the question.

Preferred Contact Method:* Phone Email

The Contact Method example above is written as follows:

<fieldset>
    <legend>Preferred Contact Method:*</legend>
    <input type=”radio” name=”contactPref” value=”Phone” id=”contactPrefPhone” required>
    <label for=”contactPrefPhone”>Phone</label>
    <input type=”radio” name=”contactPref” value=”Email” id=”contactPrefEmail” required>
    <label for=”contactPrefEmail”>Email</label>
</fieldset>

Validation, Errors, and Submitting Forms

The sooner an error can be identified, the better.
- Best case: once a user mouses or tabs away from an input field, it validates the input with a JavaScript event handler. It immediately notifies the user if the input is incorrect or incomplete.
- Acceptable case: when the user attempts to submit the form, the page performs client-side validation to verify the input is correct, and issues any relevant errors all at once.
- Inaccessible case: All validation is implemented server-side, and any errors require the user to submit the form again in its entirety. Note that server-side validation is acceptable for security purposes, if it complements similar client-side validation.
When the user is notified of errors, they are informed where the error is, and are reminded of requirements for the invalid or incomplete form fields.
If the user is submitting a form that involves a financial transaction, constitutes a legally binding agreement, or has other substantial consequences, they are provided with a way to either reverse the form submission, or correct any errors before submission.
- This is most commonly accomplished with a “Review” page before final submission of the form.

CAPTCHAs

CAPTCHAs are controversial amongst some accessibility advocates and users with disabilities. All types of CAPTCHAs present some risk of creating accessibility barriers.
- If you must use CAPTCHAs, use the more accessible reCAPTCHA v3 (external link).
- Never use the legacy CAPTCHAs asking users to identify letters, or identify which pictures contain certain imagery.

How to Test

Verify that there are visible text descriptions of the purpose of the form, and any form field instructions, including visible descriptors of any symbols to indicate required fields.
Confirm that color alone isn’t used to indicate required fields.
Manually inspect the HTML to review that each input has an associated <label> and that each grouped question, like radio buttons and dropdowns, have appropriate <fieldset> and <legend> elements.
Answer questions with incorrect input, and verify that the input is validated client-side, and that you are provided with clear descriptions for how to revise your input. Confirm that errors are indicated with identifiers beyond just color.
If completing a form that has substantial consequences, ensure you are provided the opportunity to review and revise your answers before submission.

Qualtrics Forms

Qualtrics is a reasonably accessible third party forms service. They offer a variety of question types. Most of the standard question types are accessible, but a few of the more complex types, including those with drag-and-drop answers, are not accessible.. Review the following resources to make sure you are choosing accessible question types within your Qualtrics forms.