Web Form Accessibility: Where Sites Fail WCAG

This is the failure automated tools were built to catch, and it's still the most common one on the web. A visible label sitting near an input is not the same as a label attached to it. Sighted users infer the connection from proximity; a screen reader can only announce a relationship that exists in the markup. Wire each field with a real <label for> or an associated accessible name (opens in new tab), and the field announces itself correctly.

The recurring offenders we see across thousands of scans:

• Placeholder text used as the label. Placeholders vanish the moment someone starts typing, aren't reliably read by assistive tech, and usually fail contrast. A placeholder is a hint, never a label.
• Icon-only and search fields. A magnifying-glass search box or a bare email input in a footer frequently ships with no accessible name at all — a screen reader just says “edit text.”
• Custom checkboxes, radios, and toggles. Styled controls built from <div>s instead of native inputs lose their label, role, and state unless you rebuild all three by hand.

An automated scan is genuinely good here — missing and broken label associations are exactly the kind of programmatic fact a tool can verify. Run your key pages through our free WCAG checker and it will flag unlabeled fields down to the element. That is the easy 30–40%. The rest needs a human.

Unplug your mouse and try to complete your own signup or checkout using only the keyboard. It is the fastest, cheapest accessibility test in existence, and most forms fail it within a few seconds. Watch for the classics:

• Focus you can't see. If you can't tell which field is active as you press Tab, neither can a sighted keyboard user. Never remove the focus outline without replacing it with something at least as visible.
• Illogical tab order. Focus should move the way the form reads. Positive tabindex values and CSS that reorders fields visually are the usual culprits when it doesn't.
• Custom widgets that trap or skip focus. Date pickers, combo boxes, and multi-step wizards built from scratch often can't be operated — or exited — with a keyboard at all.

Keyboard operability is a WCAG 2.2 Level A requirement — the baseline, not a nice-to-have. We break down the full checklist in our WCAG 2.2 guide, and 2.2 added criteria that hit forms specifically, like not burying already-entered information behind a sticky header (Focus Not Obscured) and not forcing people to re-enter data they already gave you (Redundant Entry).

You don't need a consultant on retainer to make real progress. A repeatable, honest process gets you most of the way:

1. Scan first to clear the mechanical failures. Run your form pages through our ADA compliance checker to catch missing labels, contrast failures, and broken markup. If you have your own OpenAI, Anthropic, or Gemini API key, our optional AI fix suggestions are bring-your-own-key — you pay your provider directly, we add no markup — and turn a flagged issue into a concrete code change.
2. Then test by hand, the way a user would. Complete the form with the keyboard only. Submit it wrong on purpose and confirm every error is announced and reachable. Turn on a screen reader — VoiceOver and NVDA are free — and listen to whether each field makes sense out of context.
3. Work from a checklist so nothing slips. Our WCAG checklist maps each check to the criterion it satisfies, so you can show your work if anyone ever asks.
4. Re-check after every change. A form that passed last quarter can regress the next time a developer restyles a button or a marketing tool injects a new pop-up. That is what ongoing monitoring is for — catching drift before a tester does.

Do the mechanical scan, do the manual pass, and repeat it on a schedule. No tool — ours included — can promise your forms are compliant or make you lawsuit-proof. What it can do is find the failures that are actually there, and give you a documented, honest record that you looked and fixed what you found. That is what holds up.