Skip to content
Accessible Forms Guide: Labels, Errors & Best Practices

Accessible Forms Guide: Labels, Errors & Best Practices

4 min read

Why Form Accessibility Matters

Forms are where users accomplish tasks: signing up, making purchases, submitting applications, and contacting support. When a form is inaccessible, it does not just create a poor experience — it blocks people from completing essential actions. For many businesses, inaccessible forms mean lost customers and potential legal liability.

WCAG has multiple success criteria that apply to forms, including 1.3.1 (Info and Relationships), 2.4.6 (Headings and Labels), 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions), and 3.3.3 (Error Suggestion). This accessible forms guide covers the patterns and practices you need to meet these requirements.

Labels: The Foundation of Accessible Forms

Every Input Needs a Visible Label

Every form field must have a visible text label that clearly describes what information is expected. The <label> element with a matching for attribute is the most robust method:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

This creates a programmatic association between the label and the input. Screen readers announce the label when the user focuses the input, and clicking the label focuses the input, which increases the click target size.

Avoid Placeholder-Only Labels

Using a placeholder attribute as the sole label is a common anti-pattern. Placeholders disappear when the user starts typing, removing the label at exactly the moment the user needs it most. Placeholders also typically have insufficient color contrast and are not consistently announced by all screen readers.

Always use a visible <label> element. Placeholders can supplement but never replace labels. Use them for format hints (“e.g., [email protected]”) rather than field descriptions.

Use <fieldset> and <legend> to group related inputs like radio buttons, checkboxes, and multi-field sets (e.g., date of birth with separate day, month, and year fields):

<fieldset>
  <legend>Preferred contact method</legend>
  <label><input type="radio" name="contact" value="email"> Email</label>
  <label><input type="radio" name="contact" value="phone"> Phone</label>
  <label><input type="radio" name="contact" value="text"> Text message</label>
</fieldset>

Without a <fieldset> and <legend>, a screen reader user tabbing to one of the radio buttons would hear “Email, radio button” but have no context about what question “Email” is answering.

Required Field Indicators

Mark required fields clearly. The most accessible approach combines a visual indicator with a programmatic one:

<label for="name">Full name <span aria-hidden="true">*</span></label>
<input type="text" id="name" name="name" required aria-required="true">

Include a note at the top of the form explaining the convention: “Fields marked with * are required.” The required attribute and aria-required="true" ensure assistive technology announces the field as required.

Error Handling That Works for Everyone

Identify Errors Clearly

When validation fails, users need to know three things: that an error occurred, which field has the error, and what they need to do to fix it.

Error summary: Display a list of all errors at the top of the form after submission fails. Each error should link to the corresponding field:

<div role="alert">
  <h2>There are 2 errors in this form</h2>
  <ul>
    <li><a href="#email">Email address is required</a></li>
    <li><a href="#password">Password must be at least 8 characters</a></li>
  </ul>
</div>

The role="alert" ensures screen readers announce the error summary immediately.

Inline errors: Display the specific error message near each problematic field and associate it programmatically:

<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<p id="email-error" class="error">Please enter a valid email address</p>

The aria-describedby links the error message to the field, and aria-invalid="true" tells assistive technology that the current value is incorrect.

Do Not Rely on Color Alone

Error states must not be indicated only by changing a border to red. Add an error icon, error text, and the aria-invalid attribute. This ensures that color blind users and screen reader users both understand the error state.

Provide Error Prevention

For actions with significant consequences (financial transactions, legal agreements, data deletion), provide at least one of:

  • Reversibility: Allow the user to undo the submission.
  • Confirmation: Show a summary page and ask the user to confirm before final submission.
  • Review: Let the user review and correct information before submitting.

Form Layout and Structure

Logical Tab Order

Form fields should follow a logical sequence that matches the visual layout. Do not use CSS to visually reorder fields without changing the DOM order, as keyboard users will encounter them in the DOM sequence.

One Column Layouts

Single-column form layouts reduce confusion about which fields belong together and create a predictable tab order. Two-column layouts can work for short, tightly related field pairs (like first name and last name), but they risk ambiguity on narrow screens.

Clear Submit Buttons

The submit button should be a <button type="submit"> element with descriptive text. Avoid generic labels like “Submit.” Use action-specific labels like “Create account,” “Place order,” or “Send message.”

Progress Indicators for Multi-Step Forms

For multi-step forms, provide a progress indicator showing the current step, total steps, and step labels. Each step should have a descriptive heading. Allow users to navigate back to previous steps without losing entered data.

Input Types and Autocomplete

Use Correct Input Types

HTML5 input types trigger appropriate virtual keyboards on mobile devices and enable browser-level validation:

  • type="email" — Shows the @ key on mobile keyboards.
  • type="tel" — Shows a numeric keypad.
  • type="url" — Shows URL-friendly keys.
  • type="number" — Shows a number keypad (use cautiously, as it has accessibility issues for non-numeric-calculation fields like phone numbers or zip codes).
  • type="date" — Provides a native date picker.

Enable Autocomplete

The autocomplete attribute helps users fill out forms faster and reduces errors. It is also a WCAG 2.1 requirement (1.3.5 Identify Input Purpose) for common fields:

<input type="text" name="name" autocomplete="name">
<input type="email" name="email" autocomplete="email">
<input type="text" name="address" autocomplete="street-address">
<input type="text" name="city" autocomplete="address-level2">

This is especially helpful for users with motor or cognitive disabilities who find typing difficult.

Common Accessible Forms Mistakes

Custom Dropdowns Without ARIA

Custom-styled dropdown menus built with <div> elements often lack keyboard navigation, proper ARIA roles, and screen reader announcements. Either style the native <select> element or build a custom dropdown with role="listbox", role="option", arrow key navigation, and proper focus management.

Disabling the Submit Button

Graying out the submit button until all required fields are valid creates confusion. Users cannot tell why the button is disabled, especially screen reader users. Instead, keep the button enabled and display validation errors on submission.

Timeout Without Warning

If your form session expires, warn the user before timeout and provide an option to extend the session. Sudden data loss due to timeout is a significant accessibility barrier for users who take longer to complete forms.

CAPTCHA Without Alternatives

Traditional image CAPTCHAs are inaccessible to screen reader users and difficult for many people with cognitive disabilities. Use alternatives like honeypot fields (hidden fields that only bots fill out), server-side rate limiting, or invisible CAPTCHA solutions that do not require user interaction.

Testing Your Forms

  1. Keyboard-only testing — Complete every form on your site using only a keyboard. Can you reach every field, select every option, and submit?
  2. Screen reader testing — Navigate forms with VoiceOver, NVDA, or TalkBack. Are labels announced correctly? Are errors described clearly?
  3. Automated scanning — Use the wcagkit ARIA validator to catch missing labels, incorrect ARIA attributes, and improper form structure.
  4. Error path testing — Intentionally trigger every validation error and verify the error messages are clear, associated with the correct field, and announced by screen readers.

Conclusion

Accessible forms are not just a legal checkbox. They directly impact whether users can do business with you. The core principles are straightforward: label every field, handle errors clearly, maintain logical structure, and test with real assistive technology.

Audit your existing forms with the wcagkit ARIA validator to catch missing labels and improper associations, then verify contrast on your form elements with the contrast checker. Accessible forms lead to higher completion rates for all users, not just those using assistive technology.