Building Accessible Forms That Pass WCAG 2.2

I have audited over a hundred websites for WCAG conformance, and the same component fails more often than everything else combined: the form. Contact forms, checkout forms, signup forms, quote request forms. A site can have perfect heading structure, solid color contrast, and alt text on every image, then fail the audit on a single checkout page because the developer used placeholder text as the only label.

This matters twice over. Forms are where money changes hands and leads come in. When a screen reader user cannot complete your checkout, you lost a sale. When an ADA demand letter arrives, the plaintiff’s expert will cite the form first because it is the easiest failure to document. Fixing forms is both a revenue decision and a risk decision.

The Failure Patterns Auditors See Every Week

Four patterns account for the majority of form-related WCAG failures I document in audit reports.

First, placeholder-only labels. The designer wanted a clean look, so the visible label got deleted and the placeholder became the label. The placeholder disappears the moment the user types, it usually fails contrast requirements, and some older assistive technologies ignore it entirely. This fails WCAG 1.3.1 (Info and Relationships) and often 3.3.2 (Labels or Instructions).

Second, labels that exist visually but are not programmatically associated. A <div> sitting above an input looks like a label to a sighted user. To a screen reader it is just stray text. Without a for and id connection, the user hears “edit text, blank” with no idea what to type.

Third, errors shown only in color. The field border turns red and nothing else happens. A user with red-green color blindness sees nothing. A screen reader user hears nothing. This fails 1.4.1 (Use of Color) and 3.3.1 (Error Identification).

Fourth, lost focus after submission. The user submits, the page reloads or a success message renders, and keyboard focus resets to the top of the page or drops into the void. The user has to tab through the entire header and navigation again to find out whether the form worked.

If any of these sound familiar, our accessibility audit guide covers the broader audit context these failures live in.

Labels and Programmatic Association: 1.3.1 and 1.3.5

Every input needs a visible label, and that label needs a programmatic connection to the field. The correct pattern has not changed in twenty years:

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

The for attribute must match the input’s id exactly. Clicking the label then focuses the input, which also helps users with motor impairments by doubling the tap target.

If you genuinely cannot show a visible label (a search box next to a magnifying glass icon is the only case I accept), use aria-label:

<input type="search" aria-label="Search this site" name="q">

If you use aria-label, make sure it matches the visible text. Otherwise speech input users cannot activate the field by the name they see, and screen reader users hear something different from what sighted users read.

Now the part most developers skip: autocomplete. WCAG 1.3.5 (Identify Input Purpose) requires the correct autocomplete token on fields that collect information about the user. Name, email, phone, street address, credit card. The tokens come from a fixed list in the HTML spec: name, given-name, family-name, email, tel, street-address, postal-code, cc-number, and so on. This helps users with cognitive disabilities and memory impairments because the browser fills known values instead of forcing recall.

Grouped fields like radio buttons and checkboxes need a <fieldset> and <legend> so the group question (“Shipping method”) is announced with each option. Without it, a screen reader user hears “overnight, radio button, 1 of 3” with no question attached.

Error Identification and Suggestions: 3.3.1 and 3.3.3

WCAG 3.3.1 requires that errors be identified in text and described to the user. A red border is not enough. WCAG 3.3.3 goes further: if the fix is known, suggest it. “Invalid input” fails. “Email address must include an @ symbol, for example [email protected]” passes.

The accessible pattern ties three things together: aria-invalid on the field, an error message element, and aria-describedby connecting them.

<label for="email">Email address</label>
<input
  type="email"
  id="email"
  name="email"
  autocomplete="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error" role="alert">
  Enter a valid email address, for example [email protected].
</p>

The role="alert" makes the message announce automatically when it appears, so the user does not have to hunt for it. For errors detected on submit rather than inline, collect all errors in a summary box at the top of the form, move focus to it, and link each item to the field that needs fixing.

One caution on inline validation: do not announce errors while the user is still typing. Validate on blur or on submit. A screen reader user hearing “invalid email” after every keystroke will abandon your form.

Focus Management and the New WCAG 2.2 Criteria

WCAG 2.2 became the current W3C recommendation in October 2023, and it added criteria that hit forms directly. You can read the full specification at the W3C WCAG 2.2 recommendation.

Three of the new criteria matter most for forms:

• 2.4.11 Focus Not Obscured (Minimum). When a field receives keyboard focus, it cannot be fully hidden by sticky headers, cookie banners, or chat widgets. I see this constantly: the user tabs to a field and a sticky newsletter bar covers it. Test by tabbing through the form with your sticky elements in place.
• 3.3.7 Redundant Entry. Do not force users to re-enter information they already provided in the same session. The billing-address-same-as-shipping checkbox exists for this reason. Copy the values or auto-populate them.
• 2.5.8 Target Size (Minimum). Click targets must be at least 24 by 24 CSS pixels, with spacing exceptions. Tiny checkboxes and cramped radio buttons on mobile are the usual failures.

After submission, manage focus deliberately. On a single-page app, move focus to the success message or the error summary using tabindex="-1" and element.focus(). Never leave focus on a removed element; when the DOM node disappears, focus falls back to document.body and the keyboard user starts over from the top.

Also keep focus visible. WCAG 2.4.7 requires a visible focus indicator, and the default browser outline is the cheapest correct answer. If your designer insists on removing outlines, replace them with something at least as strong. A 2-pixel solid outline with adequate contrast works. A subtle box shadow that disappears against your brand background does not.

CAPTCHA Without Blocking Humans

Traditional CAPTCHAs are an accessibility dead end. Visual puzzles exclude blind users. Audio CAPTCHAs are often harder than the visual version. WCAG does not ban CAPTCHA outright, but any challenge must have an accessible alternative, and in practice the accessible alternatives are weak.

The 2026 answer is invisible or near-invisible bot detection. Cloudflare Turnstile runs checks in the background without a puzzle in most cases. Honeypot fields (a hidden input that only bots fill) catch a surprising amount of spam with zero user friction. For forms that genuinely need a challenge, email or SMS verification moves the proof step to a channel the user already handles accessibly.

I have replaced puzzle CAPTCHAs with Turnstile plus a honeypot on three client sites this year. Spam volume stayed flat and form completion went up on all three. The puzzle was never earning its keep.

Testing With NVDA and VoiceOver

Automated scanners catch maybe 30 to 40 percent of form issues. The label association and contrast problems, yes. The lost focus, the confusing error flow, the announcements that fire at the wrong time, no. You need a real screen reader pass. I covered the tooling and reporting workflow in our post on AI-assisted accessibility auditing, and it pairs well with the manual steps below.

For NVDA on Windows (free, from nvaccess.org):

1. Start NVDA, open the form in Chrome or Firefox.
2. Press Tab to move field to field. Confirm every field announces its label, its type, and its required state.
3. Submit the form empty. Confirm each error is announced and that focus lands somewhere sensible.
4. Type a bad email value and tab away. Confirm the suggestion text is announced via the described-by relationship.
5. Press NVDA key + F7 to open the elements list and confirm every input appears with a proper label.

For VoiceOver on macOS or iOS: enable it with Command + F5 (or triple-click the side button on iPhone), then swipe or use Control + Option + arrow keys through the form. The checks are the same. Pay extra attention on iOS to whether error text is reachable by swiping, since users often move sequentially rather than jumping between fields.

Budget one hour per form template for a first pass, twenty minutes for retests. It is the cheapest conformance insurance you will ever buy.

When Not to Over-Engineer

A few honest trade-offs. Not every field needs an autocomplete token; 1.3.5 only applies to fields about the user, so a project description textarea is fine without one. Error suggestion (3.3.3) only applies when the system knows the fix, so do not fabricate hints for genuinely ambiguous input. And if your form is a two-field newsletter signup, a full error summary box at the top is overkill; inline errors with role="alert" are enough.

Also, resist the urge to wrap everything in ARIA. Native HTML elements carry the right semantics for free. Every aria-* attribute you add is a maintenance liability and a chance to lie to assistive technology. The first rule of ARIA remains: do not use ARIA if a native element does the job.

The Bottom Line

Accessible forms come down to five habits: visible labels tied to inputs with for and id, autocomplete tokens on personal data fields, text-based error messages connected with aria-describedby, deliberate focus management on submit, and bot protection that does not punish humans. Get those right and you pass the form portion of a WCAG 2.2 audit while removing friction for every user, not just users with disabilities.

If you want the wider conformance picture, start with our WCAG 2.2 conformance guide and the web compliance overview. And if your forms are due for an audit before a procurement deadline or a demand letter forces the issue, that is exactly the work we do. Forms are where accessibility stops being a checkbox and starts being revenue.