ADA compliant forms: what WCAG asks of every field

Why the form is where a site fails

A contact form, a booking form or a checkout is the part of a small-business site that does the business. It is also where the Department of Justice's web guidance points: "inaccessible online forms" is one of the six barriers it names, next to poor contrast and missing alt text. A visitor who cannot tell which box is the phone number, or who presses Send and hears nothing back, leaves without booking.

The most common fault is also the easiest to fix. WebAIM's 2026 scan of the top million home pages found missing form input labels on 51% of them, the third most common failure it detected.

The ADA itself has no form rules. When people say "ADA compliant forms" they mean forms that meet WCAG, the standard the Department of Justice points to; the guide to what the law asks of a website covers that link. What follows is the WCAG 2.2 Level AA reading, field by field.

Labels you can see, not placeholders

A label does two jobs. It tells a sighted visitor what goes in the box, and, tied to the box in code, it is what a screen reader says when the box gets focus. The second job is 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value, both Level A: a label that only sits near a field, without the link in code, is read by nobody.

The usual shortcut is grey text inside the box. W3C's forms tutorial is blunt about it: placeholder text "is not a replacement for labels". It disappears the moment someone types, so a visitor checking the form before sending cannot see what each box was for, and browsers usually draw it in a grey too faint for 4.5:1.

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

Two rules follow from the label. Keep the words people see in the field's name in code (2.5.3 Label in Name): someone using voice control says "click Send booking request", and it only works if the button's name contains those words. And put a group of radio buttons or checkboxes inside a fieldset with a legend, so "Yes" is read with the question it answers.

Required fields and instructions

Say which fields are required in words, either once above the form or in each label, and say the format a field expects before anyone gets it wrong: "Expiry date (MM/YYYY)", not an error after the fact. W3C's own example puts "(required)" in the label and adds the required attribute, which tells assistive technology as well.

A red asterisk alone fails twice: the colour says nothing to someone who cannot tell red from black (1.4.1 Use of Color, Level A), and the star means nothing until the form explains it. The same goes for an error shown only as a red border. Our guide to colour as the only cue shows how this looks to a visitor who sees no hue.

The border matters for its own reason. When a field's border is the only thing that shows where to type, W3C's notes on 1.4.11 Non-text Contrast (AA) ask for 3:1 between that border and the page around it. Our colour contrast requirements explain how to measure it.

<label for="phone">Phone (required)</label>
<input id="phone" type="tel"
  autocomplete="tel" required>

This site's contact form takes the first route: one line, "All three fields are required", above three labelled fields, with nothing marked by colour.

Error messages that say how to fix the problem

"Invalid input" meets neither. A message that works names the field, says what is wrong and, when the form knows, says what to type instead. It sits next to the field, is linked to it in code with aria-describedby, and the field is marked aria-invalid="true" so a screen reader says "invalid entry" when it lands there.

Try it below. The demo is pre-filled with a missing name and an email address without its ending. Press Send: focus jumps to a summary that counts the problems, each one a link to its field, and the email message suggests the fix. Correct both and send again: the confirmation is announced and everything you typed is still there.

<label for="email">Email address (required)</label>
<input id="email" type="email" autocomplete="email"
  required aria-invalid="true"
  aria-describedby="email-error">
<p id="email-error">Add the ending after the @ part,
  for example maria@riverbakery.com.</p>

A form that takes money or makes a commitment has one more Level AA rule, 3.3.4 Error Prevention (Legal, Financial, Data): the submission can be undone, or is checked with a chance to correct it, or can be reviewed and confirmed before it is final. A "Review your order" step meets it.

Autocomplete, and never asking twice

1.3.5 Identify Input Purpose, Level AA, asks that a field collecting information about the visitor says in code what that information is. WCAG lists 53 such purposes, taken from HTML's autofill list, and in HTML the autocomplete attribute carries them. The browser can then fill the field from what it already knows, which spares a visitor with a memory or motor disability from typing their own address for the hundredth time. It applies only to information about the visitor: a field for a gift recipient's name needs no token.

autocomplete="name"
autocomplete="email"
autocomplete="tel"
autocomplete="organization"
autocomplete="street-address"   (or address-line1, address-line2)
autocomplete="postal-code"
autocomplete="username"
autocomplete="current-password"  (sign-in)
autocomplete="new-password"      (sign-up)

Redundant Entry is the website's job, not the browser's: W3C says browser autocomplete is not enough to meet it. Inside one process, such as a checkout or a booking, an answer already given is filled in again or offered to pick. It does not ask you to remember anything between visits, and it allows a second entry where that is essential, where security needs it (confirming a new password) or where the earlier answer is no longer valid.

The checkbox is the pattern W3C gives as an example. Untick it and the billing fields appear, each with its own billing token, so a browser fills the right set.

Keyboard, focus order and target size

Put the mouse away and fill in your own form with Tab, Shift+Tab, the arrow keys, Space and Enter. Every field, date picker and button has to work that way (2.1.1 Keyboard, Level A); the focus has to travel in the order a person reads (2.4.3 Focus Order, A); and you have to see where it is (2.4.7 Focus Visible, AA). Our guide to focus indicators covers the ring, and the focus order checklist walks the order.

Two habits break the order. A positive tabindex forces a sequence that drifts out of step with the layout the next time someone edits the form, which W3C lists as a failure of 2.4.3 (F44); leave the source order alone instead. And a menu that submits the form or jumps the page the moment an option is chosen fails 3.2.2 On Input (A) unless the visitor is told first: a keyboard user arrowing through the options never gets past the first.

New in WCAG 2.2, 2.5.8 Target Size (Minimum), Level AA, asks that things you click or tap are at least 24 by 24 CSS pixels, or have enough space around them that a 24-pixel circle on each does not touch its neighbour. A checkbox the browser draws at its own size, untouched by your styles, falls under the criterion's user agent exception; a custom one drawn at 16 pixels does not. The fields and buttons on this page are 44 pixels tall.

CAPTCHAs, sign-in and time limits

A CAPTCHA asks a visitor to prove they are human, and for a blind visitor or one with a cognitive disability it is often the one step they cannot pass. WCAG allows one only on terms: under 1.1.1 Non-text Content, Level A, its purpose has to be described in text, and another form of CAPTCHA has to be offered that uses a different sense, such as audio beside a picture.

For a sign-in form, the practical reading from W3C's Understanding page is short:

• Let password managers fill the fields: a labelled username field and a password field with autocomplete="current-password".
• Never block paste in the password or code fields. Blocking it fails the criterion.
• Do not split a one-time code into six boxes that accept only one pasted digit.
• Offer a way in that needs no memory at all, such as a sign-in link sent by email, or a passkey (WebAuthn) that unlocks with a fingerprint, face or PIN.
• A puzzle CAPTCHA at sign-in needs one of those alternatives. An audio version you have to type out does not count. A picture test that only asks you to recognise objects is allowed at AA, though W3C advises avoiding it.
• A "show password" button is not required, but W3C names it as a help.

Most small-business forms do not need a CAPTCHA at all. This site's contact form has none: it stops bots with a hidden field people never see or reach, a signed token, and a limit on messages from one connection. On WordPress, some accessibility plugins add missing labels to the standard search and comment forms; our comparison of WordPress accessibility plugins and themes shows which ones, and what a plugin cannot fix in a form you built.

Time limits are the last gate. If a form or a session times out, 2.2.1 Timing Adjustable (Level A) asks that the visitor can turn the limit off, set it to at least ten times its length, or be warned before it runs out and given at least 20 seconds to extend it with one simple action, at least ten times. Live auctions, limits that are essential and limits longer than 20 hours are exempt. A booking form that wipes itself after ten idle minutes, with no warning, fails.

Test your own form in ten minutes

1. Fill it in with the keyboard only. Can you reach, use and leave every field, and see where you are?
2. Click each label. If the cursor does not land in its field, the label is not tied to it.
3. Send it empty. Does every error name its field, say what to do, and keep what you typed?
4. Turn the colour off in your screen settings. Can you still tell required fields and errors?
5. Let the browser autofill your name, email and address. Does it pick the right boxes?
6. Listen to it once with a free screen reader; our screen reader guide for owners shows how.

The table below is the whole list at WCAG 2.2 Level AA. Our WCAG 2.2 AA checklist lists each of these criteria with a plain test to run, and prints.

This is general information, not legal advice. For your own situation, ask a lawyer.