How to design accessible forms: labels, errors, autocomplete and CAPTCHAs

Accessible forms decide whether a visitor becomes an enquiry. If someone can’t tell which field wants their phone number, can’t find the error that stopped them, or can’t solve the puzzle guarding the Send button, they leave, usually without telling you why.

Most fixes are ordinary HTML used properly, plus careful wording, and each maps to a WCAG 2.2 criterion. For which fields to ask for, see web form design; for accessibility beyond forms, start with our practical guide to web accessibility.

Accessible forms: the short answer

An accessible form works as well with a keyboard, screen reader, voice control, magnifier or autofill as with a mouse. That means:

1. A visible, connected label on every field, never a placeholder alone.
2. Related options grouped with fieldset and legend.
3. Required fields and format rules in words, before the field.
4. autocomplete attributes on the visitor’s own details.
5. Errors that explain the fix, next to the field and announced.
6. Success and status messages that screen readers announce.
7. No re-entry, no surprise time limits and no puzzle-only barriers.

Form field labels and structure

Give every field a visible, connected label

Every field needs a visible label connected in code: a <label> whose for matches the field’s id (WCAG 1.3.1, 3.3.2 and 4.1.2). Screen readers announce it on focus, and clicking it focuses the field, a bigger target for everyone. Yet missing labels regularly rank among the six most common issues in the WebAIM Million, an annual scan of the top million home pages.

• Placeholders aren’t labels. They vanish once someone types and are often too pale to meet the 4.5:1 contrast WCAG asks of normal-size text.
• Keep the visible words in the accessible name. Voice control users say what they see, such as “click Email address”. An aria-label that says something different breaks the command (2.5.3 Label in Name).

Group related questions with fieldset and legend

Wrap each set of radio buttons or checkboxes in a <fieldset> with the question as a short <legend>, such as “How should we contact you?”, so screen reader users hear what the options answer. Do the same for a date split into day, month and year.

Put hints and required markers before the field

Put “(required)” or “(optional)” in the label itself, and format rules (“Include your country code”) in a hint above the field, linked with aria-describedby. Hints in tooltips or after the input are easy to miss, especially when zoomed in. Don’t mark required fields by colour alone (1.4.1 Use of Color) or an unexplained asterisk, and add required or aria-required="true" so screen readers announce them.

Use native controls that are easy to see and tap

Standard selects, radio buttons and checkboxes have keyboard and screen reader support built in; custom dropdowns and date pickers often don’t. Test any custom control before sign-off, and let people type dates.

Three more AA checks apply, two of them new in WCAG 2.2: whatever shows where a field is, usually its border, needs 3:1 contrast against the background (1.4.11); tick boxes and other targets need to be at least 24 by 24 CSS pixels or well spaced (2.5.8); and a focused field must never be entirely hidden behind a sticky header, cookie banner or chat widget (2.4.11). For focus styles, see accessible navigation and visible focus.

Autocomplete attributes: let the browser do the typing

WCAG 1.3.5 Identify Input Purpose (Level AA) asks fields collecting the user’s own details to declare their purpose in code: in HTML, the autocomplete attribute. Browsers and password managers can then fill in saved details, helping people with motor or memory impairments and anyone on a phone. The tokens come from a fixed list in the HTML standard, and the mistakes are predictable:

Use these tokens only for the visitor’s own details (a “Colleague’s email” field shouldn’t offer theirs), question any autocomplete="off" on a contact or booking form, and check the rendered HTML in your browser’s inspector, not the form builder’s settings.

Accessible error messages that explain the fix

Say what went wrong and how to fix it

Check answers when someone presses Send. Errors that pop up mid-typing, or on fields someone has only tabbed past, interrupt keyboard and screen reader users. WCAG 3.3.1 Error Identification requires errors to be described in text, and 3.3.3 Error Suggestion asks you to suggest a correction when you know one:

Put each message where it will be found

Place the message between the label and the input, so it’s seen and read before the field. Link it with aria-describedby, set aria-invalid="true" on the field, pair any red with an icon and words, and never clear what the visitor typed.

<label for="email">Email address</label>
<p id="email-hint">We’ll only use this to reply to you.</p>
<p id="email-error">Enter an email address like name@example.com</p>
<input id="email" name="email" type="email" autocomplete="email"
  required aria-invalid="true" aria-describedby="email-hint email-error">

Add an error summary to longer forms

On longer forms, show a summary at the top when someone presses Send: a heading such as “There is a problem”, then each error as a link to its field. Move keyboard focus to it, and if the page reloads, start the page title with “Error:”, as the GOV.UK Design System does.

GOV.UK also switches off the browser’s own error pop-ups with novalidate and marks optional fields rather than using required. If you use required, add novalidate too: the pop-ups can’t be styled, vanish on the browser’s schedule and usually follow the browser’s language, not the page’s.

Success and status messages everyone notices

When a form sends without reloading, sighted visitors see “Thank you, we’ve received your enquiry.” Screen reader users hear nothing unless the message is built to be announced, as WCAG 4.1.3 Status Messages (Level AA) requires. Three patterns work:

• A confirmation page with its own title and heading, announced on arrival.
• A live region: a role="status" container that is already on the page before the message arrives. Inserting the container and the message together often goes unannounced.
• Moving focus to the confirmation heading, which suits multi-step flows.

Updates like “3 time slots available” need the same care; fading toasts can vanish before a magnifier user finds them.

Forms that create a financial or legal commitment, such as a paid booking, also fall under 3.3.4 Error Prevention (Legal, Financial, Data): the submission must be reversible, checked for errors, or confirmed after a review step, as in a well-designed checkout flow.

Multi-step forms: re-entry, time limits and sign-in

Two of these three criteria are new in WCAG 2.2; our WCAG 2.2 explainer covers the rest of the update.

Don’t ask for the same thing twice

Under 3.3.7 Redundant Entry, details already given in the same process must be filled in or offered as a choice: a “Same as the event address” checkbox for billing, or the email from step one carried through to the review screen. The exceptions are narrow: essential re-entry, security, or an earlier answer that is no longer valid.

Make time limits adjustable

If a form or session times out, 2.2.1 Timing Adjustable says people must be able to turn the limit off, adjust it or extend it, typically via a warning that gives at least 20 seconds to extend with a simple action. Real-time events such as auctions, limits over 20 hours and essential limits are exempt; the W3C’s example of the last is a ticket site holding seats briefly.

Watch for limits nobody designed: an expired session or security token can make a form left open in a tab fail on submit. Say so in the error, and keep the answers.

Sign in without cognitive puzzles

If customers log in to book or download quotes, 3.3.8 Accessible Authentication (Minimum) rules out steps that rely on a cognitive function test, such as remembering a password or transcribing distorted characters, unless there’s an alternative or a mechanism that helps. In practice:

• Allow paste in password and code fields, and use autocomplete="current-password" so password managers work.
• If a one-time code is split into boxes, make sure paste and autofill still fill them all.
• Offer a route without a memorised password, such as an emailed link or a passkey.

Object-recognition tests (“select every bicycle”) pass at AA but not under the AAA version, 3.3.9: a last resort at best.

Accessible CAPTCHA alternatives for enquiry forms

Image and audio puzzles are a well-documented barrier for people with visual, hearing or cognitive disabilities, as the W3C note Inaccessibility of CAPTCHA sets out. Audio alternatives exclude deafblind people and are hard work in a noisy place or a second language.

On enquiry and quote forms, quiet defences that ask nothing of people work better: a honeypot field, server-side checks and a spam filter. Two details decide whether they’re accessible:

• Hide the honeypot from everyone. Visually hiding it isn’t enough: screen reader and keyboard users can reach it and have a genuine enquiry discarded as spam. Hide it from assistive technology too, and label it “Leave this empty”.
• Test the fallback. Invisible challenges may show a puzzle to visitors they’re unsure about, which you’ll rarely see yourself. Try a private window, with a keyboard and a screen reader.

If a visible challenge is unavoidable, WCAG 1.1.1 asks for a text description of its purpose and an alternative that uses a different sense, such as audio alongside an image. Keep a phone number or email address beside the form as a puzzle-free route.

Multilingual forms: accessible in every language

A form is only as accessible as its least-translated version. For each language you serve:

• Set the lang attribute (3.1.1 Language of Page) so screen readers pronounce labels and errors correctly.
• Translate every string, including hints, errors, status messages and the confirmation email. Default plugin messages are easy to miss without a clear translation workflow.
• Accept international formats: one “Full name” field, phone numbers with a plus sign, addresses without a postcode, and unambiguous dates (03/04 means different days in different countries).
• Let longer translated labels wrap, and set dir correctly for right-to-left scripts.

A keyboard and screen reader test for your forms

Automated checkers catch missing labels, not unclear errors or silent confirmations; accessibility audits and automated checkers explains the difference. Run this on each important form, in each language.

With the keyboard only

1. Put the mouse aside and Tab through the form. Focus should follow a logical order and stay visible.
2. Use the arrow keys in radio groups, Space to tick checkboxes and Enter to send.
3. Send it with one required field empty and another wrong. Errors should appear in words beside each field, and nothing you typed should be lost.

With a screen reader

Use VoiceOver (built into Macs and iPhones), NVDA (free for Windows) or TalkBack (Android).

1. Tab through again. Each field should announce its label, type, whether it’s required and any hint.
2. Trigger an error, then fix it. The error should be read out, then stop being reported.
3. Send the form. The confirmation should be announced.

With zoom, autofill and voice

1. Zoom a desktop browser window about 1,280 pixels wide to 400%. Labels, hints and errors should stay with their fields, without sideways scrolling (1.4.10 Reflow).
2. On your phone, autofill your details. Each value should land in the right field.
3. With voice control, say “click” (“tap” on an iPhone) and a label. The right field should respond.

What to do next

Start with the form that matters most, usually your main enquiry or booking form, and note everywhere the test stopped you. Most fixes are small: a connected label, a clearer error, a missing autocomplete token.

Forms sit where UX, content, development and tracking meet, so accessibility works best planned in, not bolted on. When we design and build websites, forms get visible labels, clear errors and autocomplete from the start. For a second opinion on an existing form, tell us what your website needs.