Forms & Input Accessibility: Fixing the #1 Source of ADA Lawsuits

The Problem: Why Forms Matter

Forms are everywhere: contact forms, login pages, checkout flows, search bars, comment sections. They're also the #1 source of accessibility violations, accounting for approximately 40% of all ADA litigation complaints.

Why? Because broken forms lock out entire classes of users. A screen reader user can't identify which field is which. A keyboard-only user gets trapped. A person using voice control can't activate a button. The result: lawsuits.

1. Form Labels: The Foundation

Every input field needs an associated label. This isn't optional—it's a WCAG 2.1 Level A requirement and the foundation of form accessibility.

The Right Way (WCAG Compliant)

Use semantic HTML with <label> tags and for attributes:

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

The Wrong Way (Litigation Risk)

<!-- Label not connected to input -->
<label>Email Address</label>
<input type="email" />

<!-- Placeholder instead of label (fails) -->
<input type="email" placeholder="Email Address" />

<!-- Label visually present but not connected -->
<div>Email Address</div>
<input type="email" />
        

Why This Matters

• Screen readers need the for attribute to announce the label
• Keyboard users need labels to understand what each field is
• Voice control users need labels to activate fields (e.g., "Click email")
• The clickable area expands (better for motor disabilities)
• Mobile users get larger touch targets

2. Error Messages: Making Problems Clear

When validation fails, users must understand why and how to fix it. Inaccessible error messages cause the most litigation in form flows.

WCAG Requirements (Level AA)

• Error identification: Tell users which field has the problem
• Error suggestion: Explain what's wrong in plain language
• Programmatic association: Link the error to the input field
• Persistence: Keep the error visible while fixing

The Right Way

<label for="phone">Phone Number</label>
<input 
  type="tel" 
  id="phone" 
  name="phone"
  aria-describedby="phone-error"
  aria-invalid="true"
  value="123"
/>
<div id="phone-error" role="alert" style="color: #dc2626;">
  Phone number must be 10 digits (format: 555-1234567)
</div>
        

Why This Works

• aria-describedby links the error to the input
• aria-invalid="true" marks the field as failed
• role="alert" announces the error immediately to screen readers
• Plain language explains the fix

The Wrong Way (Litigation Risk)

<!-- Color only (fails for colorblind users) -->
<input type="tel" style="border: 2px solid red;" />

<!-- Generic error message -->
<div>Error</div>

<!-- Error not linked to field -->
<ul><li>Phone number is invalid</li></ul>
<input type="tel" />

<!-- JavaScript alert (screen reader unfriendly) -->
alert("Please enter a valid phone number");
        

3. Input Types & Validation

HTML5 input types provide native accessibility features. Using them correctly saves time and improves user experience.

Semantic Input Types (Built-in Accessibility)

<!-- Email input (validates + keyboard support) -->
<input type="email" id="email" />

<!-- Phone input (numeric keyboard on mobile) -->
<input type="tel" id="phone" />

<!-- Date input (native picker, accessible) -->
<input type="date" id="birthdate" />

<!-- Number input (spinner, validation) -->
<input type="number" id="quantity" min="1" max="100" />

<!-- Required field (browser handles validation) -->
<input type="email" required aria-required="true" />
        

Why This Matters

• Native input types trigger mobile keyboards (numbers, emails, etc.)
• Built-in validation reduces form errors by 60%
• Assistive technology understands the input purpose
• Browser handles validation messages consistently

4. Placeholders: A Common Mistake

Placeholder text is not a substitute for labels. This is one of the most common violations in forms.

The Problem

• Low contrast: Placeholder text is typically light gray (fails WCAG)
• Disappears on focus: Users forget what the field is for
• Screen readers often skip it: No programmatic connection
• Not a label: Not required by HTML spec

The Right Way: Labels + Optional Placeholder

<label for="message">Message (optional)</label>
<textarea 
  id="message" 
  placeholder="Include any additional details..."
></textarea>
        

Why This Works

• Label is always visible (high contrast)
• Placeholder provides helpful hint (doesn't disappear on focus)
• Screen reader announces the label, then the placeholder
• Both sighted and blind users understand the field

The Wrong Way

<!-- Placeholder only (no label) -->
<input type="email" placeholder="Email address" />

<!-- Low contrast placeholder -->
<input 
  type="email" 
  placeholder="Email address" 
  style="color: #999;" 
/>
        

5. Buttons: Make Them Keyboard-Accessible

Buttons must be keyboard-accessible and have descriptive text.

The Right Way

<!-- Semantic button element -->
<button type="submit">Submit Form</button>

<!-- Reset button -->
<button type="reset">Clear Fields</button>

<!-- Descriptive text (not generic "Submit") -->
<button type="submit">Create Account</button>
        

The Wrong Way (Litigation Risk)

<!-- Div masquerading as button -->
<div onclick="submitForm()">Submit</div>

<!-- Image button without alt text -->
<button><img src="submit.png" /></button>

<!-- Generic button text -->
<button>Click Here</button>
        

6. Checkboxes & Radio Buttons

Fieldsets and legends are required for grouped form controls.

The Right Way

<fieldset>
  <legend>Choose Your Subscription:</legend>
  
  <div>
    <input type="radio" id="basic" name="plan" value="basic" />
    <label for="basic">Basic ($9/month)</label>
  </div>
  
  <div>
    <input type="radio" id="pro" name="plan" value="pro" />
    <label for="pro">Pro ($19/month)</label>
  </div>
</fieldset>
        

The Wrong Way

<!-- No fieldset/legend -->
<input type="radio" name="plan" /> Basic
<input type="radio" name="plan" /> Pro

<!-- Labels not connected -->
<input type="checkbox" />
<span>I agree to terms</span>
        

7. Testing Your Forms for Accessibility

Keyboard Testing

• Use Tab to navigate through all fields
• Use Shift+Tab to go backwards
• Press Enter to submit the form
• Verify focus indicators are visible
• Check for tab traps (unable to escape a field)

Screen Reader Testing

• NVDA (free, Windows): Download at nvaccess.org
• JAWS (commercial): Most popular with disabled professionals
• VoiceOver (free, Mac/iOS): Built into Apple devices

Automated Testing

• axe DevTools (browser extension)
• WAVE (browser extension)
• Lighthouse (Chrome DevTools built-in)

Manual Checklist

• ☐ Every input has a visible, associated label
• ☐ Error messages are clear and specific
• ☐ All fields are keyboard accessible
• ☐ Focus indicators are visible (3px outline)
• ☐ Buttons have descriptive text (not "Submit")
• ☐ Color is not the only way to show errors
• ☐ Form can be submitted via keyboard
• ☐ No keyboard traps or hidden fields
• ☐ Placeholder text has sufficient contrast
• ☐ Required fields are marked clearly

Key Takeaways

• Forms are the #1 source of ADA lawsuits (40% of complaints)
• Labels are mandatory, not optional—connect them with for attributes
• Error messages must be clear, specific, and linked to inputs
• Placeholders are not labels—use both for best results
• Buttons must be semantic and keyboard-accessible
• Use semantic HTML input types for built-in accessibility
• Test with keyboards and screen readers before launch
• Fixing forms prevents lawsuits and improves user experience

Resources

• W3C Web Accessibility Tutorials: Forms
• WCAG 2.1 Success Criterion 4.1.2: Name, Role, Value
• WebAIM: Creating Accessible Forms
• NVDA Screen Reader (Free)
• axe DevTools Accessibility Checker