Form Accessibility: How to Fix Missing Labels and Build Accessible Forms

Broken:

Preferred contact method:

Email

Phone

A screen reader user tabbing to the "Email" radio button hears "Email, radio button" but has no idea what question it answers.

Fixed:

  
Preferred contact method
  
  Email
  
  Phone

Now the screen reader announces "Preferred contact method, group" when entering the fieldset, then "Email, radio button, 1 of 2" for each option.

Accessible Patterns for Every Form Element

Text Inputs and Textareas

  Your message
  

For optional fields, indicate this in the label:

Phone number (optional)

Select Dropdowns

Country

  
Select a country

  
United States

  
United Kingdom

  
Canada

Always include a default empty option so the user has a clear starting point.

Checkboxes

  
Notification preferences
  

    
    Email notifications
  

  

    
    SMS notifications
  

Required Fields

Mark required fields with both a visual indicator and the required attribute (or aria-required="true"):

  Email address *

Include a note at the top of the form: "Fields marked with * are required." The aria-hidden="true" on the asterisk prevents screen readers from announcing "star" — the required attribute already communicates that the field is mandatory.

Autocomplete for User Data

WCAG 1.3.5 requires that common input fields include autocomplete attributes so browsers and assistive technologies can identify the purpose:

Full name


Email


Phone


Street address

This helps users with cognitive disabilities by allowing browsers to auto-fill known values.

Error Messages and Validation

Accessible error handling is a critical part of form accessibility. Errors must be announced to screen readers and visually associated with the field that has the problem.

Inline Error Messages

  Email address
  
    aria-describedby="email-error"
    aria-invalid="true">
  
Please enter a valid email address.

Key attributes:

• aria-invalid="true" tells screen readers the field has an error
• aria-describedby links the error message to the field
• role="alert" causes screen readers to announce the error immediately when it appears

Error Summary

For complex forms, also provide an error summary at the top:

  
There were 2 errors with your submission

  

    
Email address is required

    
Password must be at least 8 characters

  

Each error links to the specific field, letting users jump directly to the problem.

Framework-Specific Guidance

React and Next.js

React applications commonly have form accessibility issues because JSX makes it easy to create inputs without labels. Add eslint-plugin-jsx-a11y to catch these during development:

{
  "plugins": ["jsx-a11y"],
  "rules": {
    "jsx-a11y/label-has-associated-control": "error"
  }
}

For custom form components, ensure the label association is maintained:

function FormField({ label, id, type = "text", required, error, ...props }) {
  const fieldId = id || label.toLowerCase().replace(/\s+/g, '-');
  const errorId = error ? ${fieldId}-error : undefined;

  return (
    

      
        {label} {required && *}
      
      
        type={type}
        id={fieldId}
        required={required}
        aria-invalid={error ? "true" : undefined}
        aria-describedby={errorId}
        {...props}
      />
      {error && 
{error}
}

    

  );
}

For more React-specific accessibility patterns, see our React accessibility guide.

WordPress

WordPress form plugins vary in accessibility quality:

Contact Form 7 generates accessible markup by default with proper label associations. However, custom styling can break the label-input link if you restructure the HTML.

Gravity Forms includes built-in WCAG support and generates fieldset/legend for radio and checkbox groups. Enable the "accessibility-ready" option in form settings.

WPForms provides label-input associations but may need manual configuration for complex layouts.

For any WordPress form plugin, test the output with a screen reader or A11yScope's scanner to verify the labels are properly associated. Our WordPress accessibility guide covers plugin-level accessibility in detail.

Shopify

Shopify's default themes (Dawn, Refresh) include accessible form markup for cart and checkout forms. The main risk areas are:

• Custom contact forms added via third-party apps — test these separately
• Newsletter signup forms in the footer — often missing labels
• Product option selects (size, color) — verify they have associated labels

For Shopify-specific patterns, see our Shopify accessibility guide. If you build on Webflow, our Webflow accessibility guide covers form label configuration in the Webflow Designer.

Testing Your Forms for Accessibility

Keyboard Testing

Screen Reader Testing

For a full screen reader testing workflow, see our screen reader testing guide.

Automated Scanning

Run A11yScope's free scanner against any page with forms. It detects:

• Missing elements for inputs
• Incorrect for/id associations
• Missing fieldset/legend for grouped controls
• Inputs with no accessible name (no label, no aria-label, no title)

Automated scanning catches the structural issues. Combine it with keyboard and screen reader testing for complete coverage. For more on what automated scanners can and cannot detect, see our guide on fixing issues found by automated scanners.

Quick Reference Checklist

| Element | Required | Check |

|---------|----------|-------|

| Text input | with matching for/id | Label announced by screen reader |

| Textarea | with matching for/id | Label announced by screen reader |

| Select | with matching for/id | Label and options announced |

| Checkbox group |