What Does an Accessible Form Need Beyond Labels?

What does an accessible form need beyond labels?

Error handling, mostly. Visible labels are the part everyone knows about, and they are necessary and not sufficient. The standards are far more specific about what has to happen when someone gets something wrong, and that is the part almost every marketing site skips.

This matters commercially as well as ethically. A form that rejects a submission without explaining why does not just fail a guideline. It loses the enquiry, and you never find out it happened.

Here is what the standards actually require after the label, and what I build into every form I ship.

What do the standards say about errors?

They are unusually direct. The Web Content Accessibility Guidelines success criterion on error identification states that if an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. Two requirements in one sentence: which field, and what is wrong.

The same guidance is explicit that the error must be indicated in text, and that images, colour, and other visual indicators may be used as well but do not replace it. A red border alone is not an error message.

The stated intent is to ensure that users are aware that an error has occurred and can determine what is wrong. Read that as a product requirement rather than a compliance line, because that is exactly what a lost lead looks like from the other side.

Is telling them there is an error enough?

No, and there is a separate criterion for the rest. The error suggestion criterion says that if an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.

That exception is narrow and worth understanding. It exists for cases like a login form where telling someone which half of their credentials was wrong would help an attacker. It does not cover a contact form where you know the phone number is one digit short.

The intent is stated plainly too: to ensure that users receive appropriate suggestions for correction of an input error if it is possible. If your system knows what the right format is, the user should not have to guess it.

Who does this actually help?

More people than the compliance framing suggests. The guidance notes that providing information about input errors in text allows users who are blind, have low vision, or have colour vision deficiency to perceive that an error occurred, and that it may help people with cognitive, language, and learning disabilities who have difficulty understanding why a form submission failed.

That last group is the one nobody designs for and everybody belongs to occasionally. A person filling in your form on a phone, in a hurry, between meetings, has the same practical need as someone with a permanent difficulty: tell me what went wrong in words I can act on.

Which is why I stopped treating this as an accessibility task separate from conversion work. It is the same task, argued from two directions, and it is much easier to get budget for when you say so.

How should the error message be written?

In plain language, precisely, and constructively. Nielsen Norman Group's long standing guidance is that error messages should be written in plain language that is easy to understand for non-technical users, be precise in specifying exactly what was done wrong, and be constructive in suggesting steps the user can take to correct the problem.

Those three tests kill most of the error copy I see. Invalid input fails plain language and precision. Please check your details fails all three. Enter a phone number including the country code passes all three and took no longer to write.

Do not blame the person either. If your form rejects a perfectly reasonable phone format because of a regular expression somebody wrote in a hurry, the error is yours and the message should not imply otherwise.

Where should the error appear?

Next to the field, and summarised at the top if the form is long. Putting it only at the top means someone has to hunt for the field, and putting it only beside the field means someone who submitted a long form may not see it at all.

Move focus deliberately when a submission fails. If the page simply re-renders with a red outline somewhere below the fold, a keyboard or screen reader user has no idea anything happened, and a mouse user on a phone may not either.

Keep the message visible while they fix it. Error text that disappears the moment the field is focused takes the instruction away exactly when it is needed, which is a surprisingly common pattern in component libraries.

What about the fields themselves?

Ask for less, and mark what is required in text rather than only with an asterisk. Every field you add is another chance to produce an error state you then have to handle well, so the cheapest accessibility improvement is usually deleting a field.

Labels stay visible. Using a placeholder as the label means the instruction vanishes the moment someone starts typing, which fails people with memory and attention difficulties first and everybody else eventually. I made that case separately in why form labels should be visible rather than placeholders.

Think about what you genuinely need in order to reply. Most B2B contact forms collect a company size and a budget range that nobody reads, and the cost of that is a longer form and more ways to fail. I went through that trade in designing a contact page that gets fewer useless messages.

What about success states?

Treat them with the same seriousness, because an ambiguous success is a failed submission as far as the visitor is concerned. Tell them it worked, in text, and tell them what happens next and roughly when. The text part matters for the same reason it does on an error.

A person who is not certain their message sent will either send it again or give up, and both outcomes cost you something. The duplicate is an annoyance. The abandonment is a lost enquiry you will never know about.

If the form redirects, make sure the destination confirms the specific thing that just happened rather than being a generic thank you page that could follow any action on the site.

How do you check any of this quickly?

Submit your own form badly, on a phone, and watch what happens. Leave a required field empty, put a wrong format in another, and see whether you are told which field, what is wrong, and what to do instead. That is the whole standard, tested in two minutes.

Then do the same run with the keyboard only, never touching the mouse. That single test catches more real problems than any automated scan, because it exercises focus, order, and visibility at once.

Automated tools still earn their place for the things people miss, particularly contrast, and getting that right is its own small discipline that I covered in colour contrast ratios that actually matter on a B2B site.

What should you do next?

Go to your main contact form and deliberately fail it in three different ways. Write down what the form told you each time, then compare that against the two requirements: was the specific field identified, and was the problem described in text.

Fix the worst one this week. In my experience it is almost always a validation message that tells you something is invalid without telling you what valid looks like.

Across more than seventy projects, form error handling is the single most consistently neglected part of a marketing site, and it sits directly on the path to your pipeline. If you want someone to go through yours and hand you the list, reach out and let's chat.