Accessible form design: forms everyone can complete

A form’s labels, error messages and structure decide whether a meaningful share of visitors can actually complete it. This is not a matter of convenience. The two most common failures are missing labels and colour-only error indication. Each one makes a form genuinely unusable for some visitors, not merely less pleasant.

What accessible forms require: input types, labels and required fields

Requirement	What it addresses
Every field has a genuine, programmatically associated label	Screen reader users need to know what each field is for, not just see it visually next to a label
Labels are visible and persistent, not only a placeholder	A placeholder disappears once typing starts and isn’t a reliable substitute
Errors are identified in text, not colour alone	A colour-blind or screen-reader user cannot perceive a red border with no text
Errors are associated with the specific field they relate to	A general “there are errors above” message doesn’t help a user locate which field, or why
Required fields are marked in a way assistive technology can detect	Not just an asterisk styled visually with no text equivalent
Sufficient time to complete the form	No aggressive session timeouts that lose entered data without warning

Why placeholder text is not a substitute for a visible label

A placeholder — the greyed-out example text inside an empty field — disappears the moment a user starts typing. Anyone who needs to confirm what they’re filling in partway through, or who returns to review the form, loses that context entirely. It is also inconsistently read by different screen readers. Some announce it and some don’t. That makes it an unreliable channel for essential information. A visible, persistent label alongside the field, not only a placeholder inside it, is what makes a form’s structure dependable regardless of assistive technology or user behaviour.

Why colour-only error indication fails a specific, identifiable group

A field outlined in red with no accompanying text, icon or other indicator conveys nothing to a colour-blind user. That user cannot reliably distinguish the red border from a normal one. It conveys nothing at all to a screen reader user regardless of colour perception, since colour alone isn’t announced as an error. WCAG’s requirement that errors be identified in text, and associated specifically with the field they relate to, addresses exactly this. “Email address is required” should attach to the actual email field. It should not sit in a generic banner at the top of the form.

Grouping related fields with a fieldset and legend

Where a form has genuinely related groups of fields — a set of radio buttons for one question, a billing address split across several fields — group them with a semantic fieldset and a legend element as its group label. That lets assistive technology announce the group’s purpose. Otherwise each field is presented in isolation with no indication of how they relate to one another.

Session timeouts and lost data

A form that times out and discards entered data without warning is a serious usability failure for anyone who takes longer to complete a form. That includes users relying on assistive technology, who often take genuinely longer to move through a form than a mouse user does. Where a timeout is necessary for security reasons, warn the user before it happens and offer a way to extend the session. Don’t silently discard their work.

Testing your own accessible forms

Combine the keyboard test covered on keyboard navigation with a simple visual check. Temporarily remove or override your site’s colour styling (many browser accessibility tools can simulate this) and confirm every error message and required-field indicator is still understandable without colour. Then submit the form deliberately incomplete and confirm each resulting error message is specific enough to know exactly what to fix and where.

What to ask a supplier

Ask specifically whether form labels are implemented as genuine, programmatically associated labels rather than placeholder text alone. Ask whether error messages are both text-based and tied to their specific field rather than a general summary message.

Autocomplete attributes, a small addition with real benefit

Marking common fields — name, email, address, phone — with the standard browser autocomplete attribute lets a browser correctly offer to fill them from a user’s saved information. This benefits everyone. It is particularly valuable for users with motor or cognitive disabilities, for whom typing repeated information across multiple fields is genuinely more effortful. This is a small, low-cost technical addition frequently skipped, not because it’s difficult to implement, but because it’s easy to overlook.

Instructions and help text, associated with aria-describedby where they’re actually needed

Where a field has a specific format requirement — a phone number pattern, a password complexity rule — that instruction should be visible before the user encounters an error. It should not be revealed only after a failed submission. Place format guidance near the field itself, and associate it programmatically using the aria-describedby attribute, in the same way aria-labelledby associates a fieldset with its legend. That reduces both the error rate and the frustration of discovering a requirement only after getting it wrong. A sighted user sees the guidance sitting near the field. A screen reader user needs that same association made explicit in code, not only implied by visual proximity.

Multi-step forms, and what they add to the accessibility picture

A form broken into multiple steps — common for longer checkout or onboarding flows — needs to communicate progress clearly (which step, of how many) in a way assistive technology can announce. It also needs each step’s validation and error handling to follow the same principles as a single-page form. A multi-step form that handles single-page form accessibility well but loses that discipline across step transitions is a common and easy-to-miss gap.

What to do next

Test your own key forms — contact, checkout, enquiry — for both keyboard operability and colour-independent error messaging. These two checks catch the majority of form accessibility failures on ordinary business sites. This kind of interactive functionality is covered more broadly on development as an ongoing engagement.