A form is where intent meets friction. Someone wants to buy, subscribe, request a quote, or book an appointment, and the form is the gate. If that gate doesn't work with a screen reader, doesn't respect tab order, or doesn't tell the browser what kind of data each field expects, you're excluding real people and leaving real money on the table.
The frustrating part is that most form accessibility problems are invisible during normal testing. You fill out the form with a mouse, it works, you move on. But a screen reader user hitting the same form encounters a wall of unlabeled inputs where every field announces itself as "edit text, blank." A keyboard-only user tabs through fields in random order because nobody set tabindex correctly. A mobile user on autofill gets no help because the inputs lack autocomplete attributes.
What actually breaks
The most common failure is missing labels. An <input> without a <label> associated via for and id attributes (or wrapping the input inside the label) has no accessible name. Screen readers can't tell the user what the field is for. Placeholder text is not a substitute because it disappears on focus and is not reliably announced by assistive technology.
The second most common failure is missing or incorrect autocomplete attributes. WCAG 2.1 Success Criterion 1.3.5 requires that inputs collecting user data (name, email, phone, address, credit card) include the appropriate autocomplete value. Beyond compliance, correct autocomplete speeds up form completion dramatically on mobile, where typing is slow and error-prone.
Then there's focus order. When a user presses Tab, focus should move through the form in a logical sequence that matches the visual layout. Forms that use CSS flexbox or grid to rearrange elements visually without matching the DOM order create a disconnect between what the eye sees and what the keyboard does. The user tabs from the email field to the submit button, skipping the phone number field entirely.
The legal reality
ADA Title III lawsuits targeting web accessibility hit over 4,000 federal filings in 2023, according to UsableNet's year-end report. A significant portion of these lawsuits cite form accessibility as one of the violations. The typical demand letter asks for $5,000 to $25,000 in settlement before litigation even starts. For a small business, that's a budget-breaking surprise from a form that "works fine" in Chrome.
The Form Conversion Audit checks the friction patterns that hurt conversion rates. The ADA Litigation Risk Audit scores the 12 signals plaintiff firms target first, including unlabeled forms. Between these two tools, you get both the business case (lost conversions) and the legal case (lawsuit exposure) for fixing form accessibility.
What the audit checks
The audit scans every <form> element on the page and evaluates each input against a checklist:
- Label association: Does every input, select, and textarea have an accessible name via
<label>,aria-label, oraria-labelledby? - Autocomplete hints: Do fields collecting personal data include correct
autocompletevalues (given-name,email,tel,street-address, etc.)? - Focus order: Does tab sequence match visual layout?
- Required field indication: Are required fields communicated both visually and programmatically (
requiredattribute oraria-required)? - Error handling: Do validation messages reference the specific field and get announced to screen readers via
aria-liveoraria-describedby? - Submit button: Does the form have a visible, labeled submit button (not just an
onkeypresshandler)?
Each finding links to the specific WCAG criterion it violates, so you know exactly what standard you're meeting or missing.
Fixing the common problems
Most form accessibility fixes take less than five minutes per form. Adding a <label> is one line of HTML. Adding autocomplete="email" is one attribute. Fixing tab order usually means reordering DOM elements to match the visual layout rather than fighting it with tabindex.
The harder fixes involve custom widgets. Date pickers, multi-step forms, and inline validation all introduce ARIA complexity that plain HTML handles for free. When possible, use native HTML elements (<input type="date">, <select>, <fieldset> with <legend>) instead of custom JavaScript widgets. Every custom widget needs its own ARIA role, state management, and keyboard interaction pattern, and most implementations get at least one wrong.
For sites that use forms as a core part of their business, I wrote about building lean, conversion-focused pages in The $97 Launch. A form that excludes 15-20% of potential users because of accessibility failures isn't just a compliance problem. It's a revenue problem hiding in plain sight.
Related reading
- Form Conversion Audit scores every form on the page for friction and conversion killers
- Form-Field Friction Estimator applies Zuko/Formisimo benchmark drop-off weights per field
- ADA Litigation Risk Audit flags the 12 signals plaintiff firms target first
- WCAG Accessibility Audit runs a full WCAG 2.1 AA sweep across the page
- Tab Order Audit covers the keyboard navigation side of the problem
Fact-check notes and sources
- ADA Title III web accessibility federal filings exceeded 4,000 in 2023. Source: UsableNet 2023 Year-End ADA Digital Accessibility Lawsuit Report.
- WCAG 2.1 SC 1.3.5 (Identify Input Purpose) requires autocomplete attributes for user data fields. Source: W3C Web Content Accessibility Guidelines 2.1, Level AA.
- Placeholder text is not a reliable accessible name. Source: W3C HTML Accessibility API Mappings specification, Section 5.1.
- Typical ADA demand letter settlement range: $5,000-$25,000 before litigation. Source: Seyfarth Shaw LLP ADA Title III litigation reports.
This post is informational, not legal advice. Consult an accessibility specialist for your specific compliance obligations.
