Designing ADA Compliant Forms: A Complete Guide to Accessible Inputs

How many times do you use web forms each day? Whether you log in to your bank, purchase something, subscribe to the newsletter, or fill in a contact form, web forms are an inseparable part of the internet. However, a web form that is not made according to ADA compliance requirements turns into a big wall that makes everything impossible for people with disabilities.

Screen readers, users who operate the website only by keyboard, and those with cognitive disabilities often encounter serious issues when using poorly coded inputs. Fortunately, HTML language provides you with numerous ways to build accessible forms. In this article, we will discuss everything you need to know about making web forms accessible.

1. The Basics: Explicit Labels with for Attribute

One of the biggest and most common accessibility mistakes in forms is the lack of explicit labels. Placeholders are not acceptable replacements for labels because placeholders are hidden as soon as the user starts to enter information and, thus, require more short-term memory usage. Besides, sometimes even screen readers ignore them.

Every standard input must have a label. To properly connect a label to an input you need to add the for attribute to the label and set it equal to the id of the input. Such labels are called explicit labels.

<!-- BAD: Screen readers won't know what this input is for -->
First Name: <input type="text" name="fname">

<!-- GOOD: The label is explicitly linked to the input -->
<label for="firstName">First Name:</label>
<input type="text" id="firstName" name="fname">

Bonus UI benefit: You click on a <label> and the associated input receives focus or the checkbox/radio button is checked. This larger clickable area is extremely helpful for people with motor impairments!

2. Advanced Labeling: aria-label and aria-labelledby

Sometimes the visible label ruins the visual design of the website (even though you shouldn't try to do this whenever you can). For instance, a search bar may just have a magnifying glass icon next to it, without any text saying "Search". That's where ARIA comes into play.

Using aria-label

This attribute helps you to provide an invisible text that will be heard by screen readers. Use it when there is no visible text available.

<!-- The screen reader will announce "Search this website" -->
<input type="text" aria-label="Search this website" placeholder="Search...">

Using aria-labelledby

If you have the label text on the page but it is not a standard <label> element (e.g., it is an <h3> or a <div>), you can connect the input to the existing text using aria-labelledby. This attribute takes the id of the element containing the text.

<h3 id="billingHeader">Enter your billing address</h3>
<textarea aria-labelledby="billingHeader"></textarea>

3. Image Buttons and Icon Inputs

Another common pattern in building websites is using icons instead of text for buttons (like magnifying glass for the "search" submit button or "X" for the close modal button). In case such button does not have any text at all, a screen reader user will hear just "Button" and will have no idea what the button does.

If you use an actual image as a button (<input type="image"> or an <img> element wrapped by a <button>), you need to use the alt attribute and describe the function of the button, not the image itself.

<!-- Using an image tag inside a button -->
<button type="submit">
  <img src="magnifying-glass.svg" alt="Submit Search">
</button>
<!-- Using an input type image -->
<input type="image" src="checkout-icon.png" alt="Proceed to Secure Checkout">

If you use icon fonts (like FontAwesome) or inline SVGs instead of images, you need to use the aria-label attribute for the <button>.

4. Grouping Related Inputs

Often we have groups of related inputs, like radio buttons or checkboxes. In such cases, individual labels are not enough: a screen reader user needs to know what the whole group of options is related to.

To achieve this effect, you need to wrap the related inputs in a <fieldset> tag and use the <legend> tag to provide the group's title.

<fieldset>
  <legend>Select your preferred shipping method:</legend>

  <input type="radio" id="standard" name="shipping" value="standard">
  <label for="standard">Standard (3-5 days)</label><br>

  <input type="radio" id="express" name="shipping" value="express">
  <label for="express">Express (Next Day)</label>
</fieldset>

In this case, a screen reader will announce the legend ("Select your preferred shipping method") before announcing the first input, thus providing the user with all the necessary context.

5. Instructions, Error Handling and aria-describedby

Often we need to provide some instructions in the form or show some errors after validation (e.g., "Password must be at least 8 characters" or "Invalid email address"). In case the text is shown below the input visually, the screen reader user may never hear it.

The aria-describedby attribute connects this helper or error text with the input field programmatically, just like the for attribute does for labels.

<label for="newPassword">New Password</label>
<input type="password" id="newPassword" aria-describedby="pwd-hint">
<span id="pwd-hint" class="text-sm text-gray-500">
  Must be at least 8 characters long.
</span>

Handling Errors Gracefully

In case the form validation fails, there are three crucial steps you need to take:

1. Alert the user: Bring the user's focus directly to the input with the error or to the error summary above the form.

2. Identify the error: Set the aria-invalid="true" attribute for the input field that failed validation.

3. Describe the fix: Use aria-describedby to connect the error text to the input (e.g., "Please include an '@' symbol").

6. Keyboard Navigation and Focus States

Many users with motor impairments operate the website using just the keyboard and using the Tab key to move from one input to another.

• Logical Tab Order: The tabindex of the elements in the form should follow a logical visual order (usually top-to-bottom, left-to-right). Don't use the tabindex greater than 0: this value disrupts the natural tab order of the page. Let the tab order follow the DOM order.

• Visible Focus Indicators: Whenever the user navigates to the input/button/link using the Tab key, it should have a very visible focus state. Never use CSS properties like outline: none; unless you replace it with an equally visible focus styling (like border or box-shadow color). Without visible focus indicator, the form becomes completely inaccessible for the user.

Conclusion

Making ADA compliant forms is not about adding several attributes to the elements at the end of development; it is about accepting the principle of accessibility as one of the foundations of the form. Building explicit labels, using ARIA attributes for advanced components, describing image buttons and creating a keyboard accessible form make your website accessible to all. Use our free single page scanner for a single page or our full site scanner for your entire website to easily find missing form labels and ARIA errors.