Guide · 9 min read
Accessible forms (WCAG) end to end
Labels, errors, keyboard, focus and colour — making every field usable by everyone, to WCAG AA.
Why accessibility is conversion
An inaccessible form does not just exclude people — it loses submissions you never see in the funnel, because the people who could not complete it never reach the drop-off chart. Form accessibility and form conversion rate are the same goal viewed from different angles.
The reference standard is the Web Content Accessibility Guidelines (WCAG), and level AA is the bar most legal regimes and procurement processes expect. Treat AA as the floor, not the aspiration.
Labels and structure
Every field needs a visible label that is programmatically associated with its control, so a screen reader announces "Email address, edit text" rather than "edit text". Placeholder text is not a label — it vanishes on input and fails contrast.
Group related controls (a set of radio options, an address block) so assistive technology announces the group's purpose, and give the form a logical heading structure. A picture choice option needs a real text alternative, not a decorative image with empty alt text.
Errors and validation
When field validation fails, the message must identify the field, state what is wrong, and say how to fix it — and it must be announced to assistive technology, not only shown in red. "There was an error" at the top of the page is useless to a screen-reader user three fields down.
Move focus to the first error on a failed submit and associate each message with its field programmatically. Never convey required status by an asterisk's colour alone; state it in text or markup so it survives for users who cannot perceive the colour.
Keyboard and focus
Every interaction must work without a mouse: tabbing reaches every control in a logical order, custom widgets respond to expected keys, and there are no traps where focus enters a component and cannot leave.
A visible focus indicator is mandatory — never remove the outline without replacing it with something at least as clear. For drag-based interactions like a ranking question, provide an equivalent keyboard mechanism such as up/down controls, or the question is simply unusable for many people.
Colour, contrast and motion
Meaning must never depend on colour alone: pair a red error border with text and an icon, and a selected state with a shape or check, not just a hue. Text and essential UI must meet WCAG AA contrast ratios against their background.
Respect reduced-motion preferences for page transitions in a multi-page form, and ensure the layout reflows without horizontal scrolling at high zoom and on small screens — a matrix question that becomes a tiny grid on a phone is an accessibility failure as much as a usability one.
Anti-spam without exclusion
CAPTCHAs are an accessibility hazard: image and audio challenges routinely defeat the very users assistive technology is meant to serve. Prefer a honeypot — a hidden field bots fill and humans never see — optionally paired with a server-side timing check.
This is the recurring theme of accessible form design: the inclusive choice and the robust choice are usually the same choice. A honeypot is more accessible and harder to fatigue than a CAPTCHA; clear validation helps everyone; a keyboard-operable form is also a more testable one.
Testing for real
Automated checkers catch perhaps a third of issues — missing labels, contrast failures — and miss everything about whether the form is actually operable. They are a smoke test, not a verdict.
Complete the entire form using only the keyboard, then again with a screen reader, including triggering and recovering from every validation error. The questions that survive that walkthrough are the ones that are genuinely accessible end to end.