Accessible form design: labels, instructions and error handling

Every enquiry, order and registration on your site passes through a form. If a field is unlabelled, a required marker is only a colour, or an error appears somewhere the person never looks, that transaction simply does not happen. Accessible form design is mostly a set of small structural decisions made once in a template, and they benefit everyone: people using screen readers, people navigating by keyboard, and the customer filling in an address on a bumpy bus ride. Here is how to get the four essentials right.

Labels that are visible and properly connected

Every input needs a label that stays on screen and is programmatically tied to the field. In HTML that means a label element whose for attribute matches the input's id, or the input nested inside the label.

That connection does two jobs. A screen reader announces "Full name, edit" instead of just "edit", and clicking or tapping the label moves focus into the field, which makes small targets easier to hit on a phone.

Write labels as the short noun the person is providing: Full name, Mobile number, PIN code, GSTIN. Avoid labels that are instructions in disguise, such as "Enter your details here", because a listener hears the label repeated for every field it covers.

Keep labels above or beside the field, and keep them visible while the person types. A label that vanishes the moment someone starts typing leaves anyone who was interrupted with no way of knowing what the box was for.

Instructions before the field, not after the mistake

If a field has rules, say so before the person fills it in. A password that must be eight characters, a mobile number that should be ten digits without the country code, a date in a particular format: all of that belongs in visible hint text next to the label.

Connect the hint to the input using aria-describedby pointing at the hint's id, so assistive technology reads the label and then the hint in one flow.

Also give the browser a chance to help. Setting the right type and autocomplete values means a mobile keyboard appears for phone numbers, and saved names, emails and addresses can be filled in automatically. That saves time for everyone and removes a lot of typing for people with motor difficulties.

Grouping related fields

Some inputs only make sense together. A set of radio buttons for "Preferred contact method" or a pair of fields for a delivery window need a group-level question, otherwise a screen reader user hears the options without the question they answer.

Wrap the group in a fieldset and give it a legend containing the question. The legend is announced with each option, so it stays clear which set the options belong to.

Use grouping for radio buttons and related checkboxes, and for address blocks where a heading helps. Do not wrap every single input in its own fieldset; that produces more noise than structure.

Showing which fields are required

Marking required fields with a red asterisk alone fails two ways: the colour carries the meaning, and the asterisk may be announced as "star" or skipped entirely.

A reliable approach:

• Add the required attribute so the browser and assistive technology both know.
• Put the word "required" in the label text, or explain the asterisk convention in text at the top of the form.
• Consider marking the optional fields instead when most fields are required, which reduces visual clutter.
• Never rely on colour, position or italics alone to signal the difference.

The same principle applies to any state in a form. If a field is disabled, invalid or locked, that fact needs to exist in text or in markup, not only in styling.

Error handling people can actually act on

This is where most forms fall apart. A page reloads, a red banner sits at the top saying "There were errors", and the person has no idea which of eleven fields is at fault.

What a good error experience does:

1. Names the field and the problem. "Mobile number must be 10 digits" beats "Invalid input" every time.
2. Places the message next to the field, and links it with aria-describedby so it is read when the person reaches the field.
3. Marks the field with aria-invalid="true" so its state is announced, not just coloured.
4. Uses more than colour. A red border plus an icon plus text, so the failure is visible to someone who cannot distinguish the border.
5. Summarises at the top with a list of links jumping to each faulty field, useful on long forms.
6. Moves focus to the summary or the first error after submission, so keyboard and screen reader users are taken to the problem instead of hunting for it.
7. Keeps what was entered. Clearing the form on error is a punishment, especially on a mobile connection.

For errors that appear without a page reload, put the message in a container marked as a live region so it is announced when it changes. And avoid validating a field the instant someone starts typing; waiting until they leave the field prevents a stream of errors while the entry is still half finished.

Testing your form in fifteen minutes

Put the keyboard first. Unplug the mouse and complete the form using only Tab, Shift+Tab, arrow keys, Space and Enter. You should always see where focus is, reach every control, and be able to submit. Then submit it deliberately wrong and check whether the errors are announced and reachable.

Next, run an automated check with Lighthouse or axe DevTools, which catches missing labels quickly. Finally, listen to the form with a screen reader such as NVDA on Windows or VoiceOver on Mac. Ten minutes of listening reveals more than an hour of guessing.

Fixing this once, in the template

Most sites use the same form component everywhere, so correcting the label, hint and error pattern in one place upgrades the contact form, the enquiry form and the checkout at the same time. Start with the form that earns you money, then work outwards.

If your forms are generated by a plugin or a builder you cannot modify, that is worth knowing early; our team can rebuild the important ones properly as part of a website development project, or advise on a fix through ask an expert.

Frequently asked questions

Is a placeholder enough if the label is obvious?

No. Placeholder text disappears when typing begins, is often too low in contrast, and is not a reliable label for assistive technology. Keep a real label as well.

Should I validate fields as the user types?

Validate when the person leaves the field or submits. Validating on every keystroke tells someone their email is invalid before they have finished typing it, which is both noisy and discouraging.

Do long forms need to be split into steps?

Splitting can help, provided each step shows progress, allows going back without losing data, and does not impose a time limit that people cannot extend.

What is the minimum size for form controls on mobile?

Give tap targets roughly 44 to 48 pixels of height with spacing between them, and keep input text at least 16 pixels so mobile browsers do not zoom when a field is focused.