Skip to main content

Accessible Forms: Guidelines and Best Practices

Allowing users to input data, make selections, and submit information.

Accessible Forms: Guidelines and Best Practices

Shawn Sandy (Ally.Cafe) ~

Introduction to Web Accessibility for Forms

Forms are a fundamental part of web interaction, allowing users to input data, make selections, and submit information. Ensuring forms are accessible is crucial because they are often the primary way users interact with websites, especially for tasks such as logging in, making purchases, or filling out contact information. Accessible forms enhance the user experience for everyone, including people with disabilities.

Relevant WCAG 2.2 Guidelines for Forms

The Web Content Accessibility Guidelines (WCAG) 2.2 provide several specific criteria to ensure forms are accessible. These guidelines are organized into three conformance levels: A, AA, and AAA. Here, we’ll focus on some key criteria relevant to forms.

1. Accessible Name (1.1.1 Non-text Content)

Level A: All form controls (input, textarea, select, etc.) must have accessible names. These can be provided using labels, aria-label, or aria-labelledby.

Example:

<label for="username">Username:</label>
<input type="text" id="username" name="username">

2. Input Purpose (1.3.5 Identify Input Purpose)

Level AA: The purpose of each input field collecting information about the user can be programmatically determined when appropriate. This helps browsers autofill information for users with disabilities.

Example:

<input type="email" name="email" aria-label="Email Address">

3. Error Identification (3.3.1 Error Identification)

Level A: If an input error is detected, the error must be identified and described to the user in text.

Example:

<label for="email">Email:</label>
<input type="text" id="email" name="email" aria-describedby="emailHelp">
<span id="emailHelp" class="error">Please enter a valid email address.</span>

4. Labels or Instructions (3.3.2 Labels or Instructions)

Level A: Labels or instructions are provided when content requires user input.

Example:

<label for="password">Password (8-20 characters):</label>
<input type="password" id="password" name="password" aria-describedby="passwordHelp">
<span id="passwordHelp">Your password must be 8-20 characters long.</span>

5. Error Suggestion (3.3.3 Error Suggestion)

Level AA: If an input error is detected and suggestions for correction are known, then the suggestions are provided to the user.

Example:

<label for="zip">ZIP Code:</label>
<input type="text" id="zip" name="zip" aria-describedby="zipHelp">
<span id="zipHelp" class="error">ZIP Code must be 5 digits. For example, 12345.</span>

Best Practices for Accessible Forms

  1. Use Proper HTML5 Input Types: Utilize HTML5 input types like email, tel, url, and number to provide native keyboard support and validation.

  2. Ensure Keyboard Accessibility: All form controls must be navigable and operable using a keyboard. This includes focusing on elements correctly using the tab key.

  3. Provide Clear and Concise Labels: Always associate labels with form controls. Labels should be clear and concise to avoid confusion.

  4. Implement Fieldset and Legend: For forms with multiple sections, use the <fieldset> and <legend> elements to group related controls and provide context.

Example:

<fieldset>
  <legend>Personal Information</legend>
  <label for="fname">First Name:</label>
  <input type="text" id="fname" name="fname">
  <label for="lname">Last Name:</label>
  <input type="text" id="lname" name="lname">
</fieldset>
  1. Provide Feedback: Ensure users receive immediate feedback when submitting a form, especially if there are errors. Use ARIA live regions to announce dynamic updates.

Example:

<div role="alert" aria-live="assertive" id="formFeedback">
  Please correct the highlighted errors before submitting the form.
</div>

For more information on making forms accessible, consider the following resources:

WCAG 2.2 Quick Reference

Using ARIA: Alert Role

W3C Web Accessibility Tutorials - Forms

WebAIM: Accessible Forms

The A11Y Project Checklist - Forms

Ensuring forms are accessible not only complies with WCAG 2.2 but also provides a better user experience for all users. By following these guidelines and best practices, you can create forms that are functional and accessible to everyone.

Found an error, typo, or bug please edit on github or open an issue or ticket

Edit on Github Open an issue