Skip to main content
Back to Insights

Forms that are helpful, accessible, and spam-resistant

Eric Zsigmond
Eric ZsigmondAug 28, 20265 min read

For a lot of businesses, the most important thing on the entire website is a form. The contact form, the quote request, the sign-up. It is the point where an anonymous visitor decides to raise their hand and become a real conversation. Everything else on the site, the design, the writing, the speed, exists in part to get someone to that moment. So it is worth making sure the form itself does not let them down.

A form has three jobs to do at once, and they can pull against each other. It has to be easy and pleasant to fill in, it has to work for everyone including people using assistive technology, and it has to keep out the flood of automated spam without making real visitors prove they are human by solving puzzles. Getting all three right is quiet, careful work.

Here is how we think about building forms that actually do their job.

Where a visitor becomes a conversation

It is easy to treat a form as an afterthought, a few boxes dropped at the bottom of a page. But a form is where intent turns into action. Someone has read enough, decided they are interested, and is willing to spend a moment of effort to reach you. That willingness is fragile. A confusing layout, an error message that makes no sense, or a form that simply seems not to work can lose the very people who were closest to getting in touch.

So we design forms to reduce friction at that decisive moment. Ask only for what you genuinely need, make the purpose of each field obvious, and make the whole thing feel effortless. Every extra field and every moment of confusion is a chance for someone to give up.

This is why we resist the urge to treat every form the same. A newsletter sign-up and a detailed project inquiry ask for very different levels of commitment, and a form should ask for effort in proportion to what the visitor is trying to do. The lighter the ask, the fewer the fields, and the more likely someone is to finish.

Labels and validation that help

The foundation of a good form is clarity. Every field should have a visible label that stays put, so a visitor always knows what a box is for, rather than a placeholder that vanishes the moment they start typing and leaves them guessing. The layout should follow the order people expect, and the required fields should be honestly marked.

Validation, the checking that a form does as it is filled in, should be a helpful guide rather than a scold. If an email address is missing an at-sign, say so gently, next to that field, at the moment it matters, and explain how to fix it. The goal is to help someone complete the form successfully, not to catch them out. A form that points clearly at what needs fixing feels like a helpful assistant. One that rejects the whole thing with a vague warning feels like a locked door.

Accessible by default

A form has to work for everyone, and that includes people who navigate with a keyboard instead of a mouse, and people who use a screen reader that speaks the page aloud. This is not a niche concern. It is a basic part of building a form properly, and it is also, in many places, a legal expectation.

In practice this means a few concrete things. Every field is reachable and usable with the keyboard alone, in a sensible order. Every label is properly connected to its field, so a screen reader announces what each box is for. And when something goes wrong, the error is announced clearly and tied to the field it belongs to, rather than flashing up as a color change that a screen reader never mentions. Build a form this way and it works for everyone, which is the only standard worth aiming for.

The reassuring thing about building forms this way is that the same choices that help someone using a screen reader also make the form clearer for everyone else. A visible, well-connected label, a sensible tab order, and an error message that says exactly what to do are not special accommodations bolted on at the end. They are simply what a well-made form looks like, and every visitor benefits from them.

Spam resistance that respects real people

Any form open to the public will attract automated spam. The web is full of programs that roam from site to site filling in forms with junk, and left unchecked they can bury real inquiries under a pile of nonsense. So a form needs a defense. The question is who pays the cost of that defense.

The common approach is to make every visitor prove they are human, by picking out traffic lights or deciphering warped text. It works, but it puts the burden on the real people you most want to hear from, and it can turn them away at the last step. We prefer quieter methods. A honeypot, for instance, is an invisible field that a human never sees and never fills in, but an automated program does, which gives it away without anyone noticing. Other quiet checks watch for the telltale signs of automation, like a form submitted impossibly fast.

These methods catch the vast majority of spam while staying completely invisible to a genuine visitor. When a puzzle is truly warranted, it should be a last resort for a form under real pressure, not the first thing every visitor meets. The default should be a form that trusts people and quietly filters out the machines.

Making sure the message arrives

A form that collects a message perfectly is still useless if the message never reaches anyone. This is the failure nobody notices until an inquiry is missed, because everything looks fine from the side of the visitor. They filled in the form, they saw a thank-you message, and they reasonably assume someone will get back to them. If the notification quietly failed to send, that inquiry simply vanishes.

So we treat delivery as part of the form, not an afterthought. Notifications need to be sent in a way that reliably reaches an inbox rather than getting lost or filtered away as suspicious, and it is worth keeping a record of submissions in the site itself as a safety net, so that even if an email goes astray, the inquiry is not lost. A form is only finished when the message it collects lands reliably in front of the person who needs to answer it. That last, invisible step is the one that turns a submitted form into an actual conversation.

Share this article
Eric Zsigmond
Written by
Eric Zsigmond
Co-Founder & Senior Frontend Engineer

Frontend engineer with deep expertise in Drupal theming, component-driven architecture, and modern JavaScript frameworks. Builds fast, accessible interfaces using React, SDX, and Tailwind. Obsessive about performance, pixel-perfect implementation, and clean markup. Almost every pixel on this page is his work.

Enjoyed this article?

If this resonated, imagine what we could do working together on your Drupal site.