Forms are where accessibility pays for itself

Every field keeps its label

A label sits beside or above the field and stays there once typing starts. It is what a screen reader announces, and it is what a distracted person rereads when they look back at the form.

Clicking a properly connected label should put the cursor in its field. If it does not, the two are not actually joined, and assistive technology has no idea which caption belongs to which box.

Test it the quick way: click the label text itself. If the cursor jumps into the field, the two are properly joined. If nothing happens, assistive technology has no idea which caption belongs to which box, whatever the layout looks like.

Placeholders are not labels

Grey text inside the box looks clean in a mockup. Then the reader types and the caption vanishes, taking the only instruction with it.

It fails twice over. Placeholder text is usually pale enough to fail contrast on its own, and it disappears exactly when someone checking their work needs it. Use a real label, and keep the placeholder for an example of the format.

Errors that say what to do

A red border is not a message. The reader who cannot separate that red from the surrounding gray sees an ordinary form that will not submit.

Write the problem in words, next to the field it belongs to. Say what is wrong and what a correct entry looks like. Put a short summary at the top of a long form, and move focus there, so nobody hunts for a failure they cannot see.

Error wording is worth its own pass, and accessible error messages covers what to say, where to put it, and why the message has to be announced rather than merely displayed.

Asking for less

Every field is a small tax on the visitor. Ask only for what you need to reply, which on most business sites is a name, one way to reach them, and what they want.

Fewer fields means fewer chances to trap someone, less to read aloud, and a faster finish on a phone. The most accessible question is the one you decided not to ask.

• A name, so the reply is not addressed to nobody
• One way to reach them, not three
• What they need, in their own words
• Nothing you would not read before replying
• No date of birth, account number or identifier
• No medical, health or other sensitive detail — say so on the form

Groups, required marks and the browser's help

A set of radio buttons needs a heading that announces the question, not just labels on each option. Otherwise a listener hears four answers and never learns what was asked.

Mark required fields in words as well as with an asterisk or a color. And say it before the field rather than after, so the reader knows it is required while deciding whether to fill it in.

If a form expires while somebody is filling it in, warn them and let them extend it. Plenty of people take longer than you expect, and losing a half typed message is the fastest way to lose the enquiry entirely.

Let the browser help too. Fields marked so that a browser recognizes a name, an email address or a phone number can be filled automatically, which removes most of the typing for a reader who finds typing hard.

It also removes most of the typing errors, which means fewer bounced replies and fewer wrong numbers in your inbox.

What happens after submit

Confirmation has to be announced, not merely displayed. A message that appears silently at the top of the page leaves a screen reader user unsure whether anything happened.

Say plainly that the message was sent and what happens next. Someone who cannot tell whether a form worked will send it again, or call, or give up.

Send a confirmation email as well, if you can. The visitor has just handed over their details and has no way of knowing whether the form worked, and a short acknowledgement removes the doubt that otherwise produces a second submission.

What the builder gives you

Contact forms here ship with connected labels, keyboard support and error text written in plain words. Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards.

The check can confirm a label exists. It cannot tell whether your question is clear. Nothing on this page is legal advice. Read your own form aloud before launch and see whether you would know how to answer it.

The quiet test that finds the rest

Fill in your own form badly on purpose. Leave the email blank. Put letters in the phone field. Submit it and read what comes back.

You are checking three things. Does it tell you which field is wrong, in words. Does it keep everything you already typed. Can you get back to the problem without hunting.

A form that clears itself on an error is the cruelest pattern on the web, and it is still common. The in-app assistant flags the parts a machine can see, and this deliberately clumsy attempt finds the rest.

Do the same on a phone. Small screens introduce their own failures: a keyboard covering the field being typed into, an error message scrolled out of view, and submit buttons too close to something else.