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. Use semantic HTML with <label> tags and for attributes:
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.
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
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
3. Input Types & Validation
HTML5 input types provide native accessibility features. Using them correctly saves time and improves user experience.
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.
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
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
5. Buttons: Make Them Keyboard-Accessible
Buttons must be keyboard-accessible and have descriptive text.
6. Checkboxes & Radio Buttons
Fieldsets and legends are required for grouped form controls.
7. Testing Your Forms for Accessibility
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)
NVDA (free, Windows): Download at nvaccess.org
JAWS (commercial): Most popular with disabled professionals
VoiceOver (free, Mac/iOS): Built into Apple devices
axe DevTools (browser extension)
WAVE (browser extension)
Lighthouse (Chrome DevTools built-in)
☐ 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