Accessible forms: errors that help people finish

The empty version of a form is usually the easiest one to design. Everything aligns, the example text fits, and the submit button looks reassuring. The real interface appears when someone enters an unexpected value, misses a field, or loses their connection while submitting.

Those states deserve the same attention as the initial layout. A useful form helps a person understand what happened and continue from where they were.

Put the requirement beside the decision

Consider a booking enquiry asking for a preferred arrival date. The person needs to know whether the date is required, which timezone matters, and whether submitting the form reserves anything.

I would put that information near the relevant control or action. A paragraph at the bottom of the page is easy to miss, especially on a phone. The label should remain visible after someone starts typing, so the field's purpose does not disappear with its placeholder.

The wording can prevent errors before validation runs. “Preferred arrival date” sets a different expectation from “Arrival date confirmed.” Similarly, “Send enquiry” describes a different action from “Book now.”

Make an error actionable

“Invalid input” identifies a problem without explaining how to fix it. A useful message names the field and the next step: “Enter an email address so we can reply,” or “Choose a departure date after your arrival date.”

W3C's forms guidance recommends clear feedback near the affected controls as well as overall submission feedback. It also describes associating an error with its input using aria-describedby. This gives assistive technology a relationship it can expose, beyond a visual red border. W3C guidance on form notifications.

An illustrative field in its error state could be rendered like this:

<label for="reply-email">Email address</label>
<input
  id="reply-email"
  name="email"
  type="email"
  autocomplete="email"
  required
  aria-invalid="true"
  aria-describedby="reply-email-error"
/>
<p id="reply-email-error">
  Enter an email address so we can reply.
</p>

The invalid state and error association should reflect a real validation result. When the value is corrected, update that state and remove the obsolete error. Do not leave a field permanently marked invalid because the first submission failed.

Preserve the work already done

Suppose someone writes a detailed message, submits it, and discovers that the email address is missing. Clearing every field forces them to reconstruct work the application already had.

I would retain the valid input and bring attention to what needs correction. For a long form, an error summary with links to affected fields can make the repair path easier to navigate. Keep focus behavior predictable and test the actual sequence with a keyboard.

This is especially useful when fields are spread over several screens. The person should not have to search for one red outline or remember which earlier step contained the missing answer.

Separate rejection from uncertainty

A server validation error means the submission was rejected. A network timeout may leave the client uncertain about whether the server received it. Those deserve different messages and recovery behavior.

For an enquiry form, show success only after the server confirms acceptance. If the request is still pending, describe it as pending. If the client can safely retry, preserve the submission identifier so recovery does not create another enquiry. The backend side of that contract is covered in safe API retries.

The success message also needs precise language. “Your enquiry was received” is useful confirmation. It should not imply that a reservation or payment has been confirmed when the form only sent a message.

Review the uncomfortable states

My review sequence would include an empty submission, several simultaneous errors, correcting one field, a server rejection, a slow response, and a successful completion. Check that the message stays readable at phone width and that focus remains usable throughout.

Then repeat the critical path with a screen reader. Markup can look correct while the interaction announces too much, announces nothing, or moves focus unexpectedly.

A well-designed form keeps the person oriented. At every stage, they should understand what the application needs, what it has accepted, and what they can do next.