A form should never empty itself. Keep everything the visitor typed when something is wrong, explain each error beside its field, accept ordinary phone and postal code formats, and test it on a phone.

One mistake, every field empty

A visitor fills in your quote form on a phone: name, email, phone number, and four careful sentences about the job.

They press send. The page reloads with a red line at the top saying something was wrong, and every field is blank, including the four sentences.

Some will type it all again. Many will not, and the business never learns they tried, because a form that failed sends nothing.

From inside the office the form looks fine. It works perfectly for anyone who gets everything right first time, which is how the people who built it tested it.

How forms lose what was typed

The fourth is the one nobody at the office sees. Phones drop background pages from memory, so a visitor who leaves to find a photo can return to a page that has started over.

Why the second attempt rarely happens

The visitor was willing once. That willingness is the scarcest thing a form deals with, and an empty page spends it.

Typing the message again on a phone keyboard is real effort. The visitor is also now unsure whether the first attempt went through, and nobody wants to send the same request twice.

So they do the easier thing and try the next business in the search results, whose form may be no better but has not yet let them down.

Keep everything they typed

The fix is simple to describe. When the form finds a problem, it comes back with every field exactly as the visitor left it, and only the problem marked.

That applies wherever the check happens, and especially on the server, where a check that returns a blank form is doing half its job.

Passwords and card numbers are sensible exceptions, typed again for safety. And a browser never refills a file field, so a well-built form keeps the uploaded file on the server or says plainly that it needs attaching again.

Explain the error beside the field

A line at the top saying "Please correct the errors below" makes the visitor hunt, and on a phone the problem may be three screens down.

Put each message beside, or just above, the field it concerns. Say what is wrong and how to fix it: "This phone number seems to be missing a digit" helps; "Invalid input" does not.

Do not rely on a red border alone. Some visitors cannot tell red from other colours, and a screen reader does not announce colour at all.

Stop rejecting answers that are fine

Many form errors are not the visitor's mistake. They are the form refusing an ordinary way of writing something.

Phone numbers arrive with spaces, dashes, brackets and a leading 1. Postal codes arrive in lower case, with or without the space. Names arrive with apostrophes and hyphens.

A form that demands exactly ten digits, or a postal code typed exactly as A1A 1A1, turns correct answers into errors. Accept the variations and tidy them up afterwards, on the server, where the visitor never sees it.

A worked example

A company that makes commercial awnings and canopies gets most of its work from a quote form: contact details, the width of the storefront, the type of awning, a description, and a photo of the building.

The phone field accepted only ten digits with nothing between them. Anyone who typed dashes got the page back with a red message at the top and every field empty, photo included.

The owner found out when a restaurant owner phoned to ask whether the website was broken, having tried three times from the sidewalk outside his restaurant.

The fix took a morning. The phone field now accepts any format, everything typed is kept when something is wrong, and each message appears beside its field.

The form also says, beside the photo field, that a photo can follow by email if it will not attach.

Check as they go, and again on the server

Many errors can be caught before the visitor presses send. The browser can point out an email address with no @ in it, or a required field left empty, as soon as they move to the next box.

Use this gently. A warning that appears while someone is halfway through typing is nagging, not helping, so check each field when they leave it, not on every keystroke.

The server still checks everything when the form arrives. Browser checks are a courtesy to the visitor; server checks protect the business.

Long forms and the page that reloads

For long forms, such as applications or detailed quotes, some form tools save a draft in the visitor's browser as they type. A page that reloads then comes back with its answers.

An expired security token should be handled the same way: the form comes back with the answers intact and asks the visitor to press send again, rather than discarding their work with "session expired".

Testing it on a phone

The test takes ten minutes, and it is best done by somebody who did not build the form.

Fill it in on a phone over mobile data. Get one field wrong deliberately, switch to another app halfway through, and leave it open for an hour before sending.

Then repeat it on another make of phone, since phones handle background pages differently.

The counter-case

Not every form needs all of this.

A three-field contact form, asking only for a name, an email address and a short message, loses less when it fails, and a draft-saving feature would be more machinery than it needs.

It still needs the basics: keep what was typed, explain errors beside the field, and accept ordinary formats. Those cost little and apply to any form.

The fuller treatment belongs to long forms and the forms that bring in most of the work. Whatever the length, no form should hand a visitor an empty page.

The test

  1. Make one deliberate mistake and press send.
  2. Check every field kept its answer.
  3. Read each error message as a stranger would.
  4. Type the phone number with dashes and spaces.
  5. Switch apps halfway through, then return.
  6. Leave the form open for an hour.
  7. Repeat it on another phone.

Step two matters most, because a form that keeps what was typed turns every other problem on this list into a small annoyance instead of a lost enquiry.

What should happen after a successful send is covered in thank-you pages that say nothing.

Frequently asked questions

Why does my form clear after an error?

Usually because the server checks the answers and sends back a fresh, empty form instead of the one the visitor filled in. It is a fixable setup problem.

Where should error messages appear?

Beside or just above the field they concern, saying what is wrong and how to fix it. A single message at the top makes visitors hunt for the problem.

Should the form accept phone numbers with dashes?

Yes. People write phone numbers with spaces, dashes and brackets, and postal codes in lower case. Accept the variations and tidy them on the server afterwards.

Why do phones lose half-filled forms?

Phones drop background pages from memory when another app needs it. A visitor who leaves to find a photo can return to a page that has reloaded from the start.

Are browser checks enough on their own?

No. They are a courtesy that catches simple mistakes early. The server must still check everything that arrives, because browser checks can be bypassed.

What about attached files after an error?

A browser never refills a file field. A well-built form keeps the uploaded file on the server or tells the visitor clearly that it needs attaching again.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Quote form that empties itself?

Send us the page. We will try it on two phones and show you where enquiries are slipping away.

Start a Conversation