All Articles

Accessibility

Spam Protection Needs a Fallback for Real Customers

What happens when a contact form cannot verify a request? Keep the visitor's draft, explain the next step, and review the blocked path alongside spam protection.

Chase Treadway
4 min read

Picture someone finishing a message on your contact page. They have explained what needs fixing and pressed Send. The site cannot verify the request. Now they need to know whether to try again, copy their message, or find another way to reach you.

That moment deserves attention when you add spam protection. A check sits between a visitor and the work they want to ask about. The decision to decline an uncertain request needs a customer-facing next step.

Our October 19 contact-form update added a verification step before inquiry processing. It builds on existing safeguards that retain the entered message after an error and offer an email alternative. The useful lesson is how those parts work together when verification cannot give an accepted result.

Treat an uncertain result honestly

An automated check can return a result your application accepts, a result it declines, or fail to complete. Decide what each outcome means before choosing the wording visitors will see.

In our implementation, an unaccepted verification result prevents the inquiry-processing step from running. The guard also declines processing when the check errors or takes too long. These are explicit decisions about when the online route may proceed. They do not prove that every declined visitor is a bot.

The integration uses BotID. Vercel describes BotID as an invisible check that does not ask visitors to solve a visible challenge. The application still has to decide how to handle the result. Removing a visible puzzle leaves that handling decision with the team responsible for the form.

Use language that matches what you know. If verification could not be confirmed, explain that the online request did not go through and give a useful alternative. Avoid accusing the visitor of sending spam when the result only tells you that the check was not accepted.

Keep the visitor's work within reach

Someone who has written a careful message should have a way to use it again. In our current form, error handling leaves the entered values in the open page. That is temporary page state; it should not be described as a saved draft that survives a reload or a closed tab.

The email alternative prepares a draft in the visitor's email app. They review it and send it themselves. Keep the actual address readable as well, so someone can copy it if an email app does not open as expected.

This arrangement has an operating cost: another contact route needs someone to look after it. Agree who monitors the address and what happens when a visitor reports a problem with the form. An alternative is useful when your team can follow through on it.

The tradeoff is worth making explicit. Declining uncertain online requests limits what reaches downstream processing, while asking a legitimate visitor to take another step. Preserve that person's work and make the extra step understandable.

Review the blocked path as part of the form

Ask your developer to demonstrate the declined and unavailable states using controlled test cases. A practical review should answer four questions:

  • Is the explanation useful? The visitor should know the request did not complete and what they can do next.
  • Is their message still available? Check the current page after an error, and explain any limits on keeping that text.
  • Can they use the alternative? Follow the email link, inspect the draft, and try copying the visible address.
  • Can they reach and understand the next step? Include keyboard navigation and appropriate assistive-technology checks, including how the error is announced.

W3C's accessibility development guidance recommends avoiding CAPTCHA where possible and providing alternatives when it is needed. It also covers keyboard access. Use that guidance to review the whole interaction; an invisible check alone does not establish that a form is accessible.

Our guard tests cover accepted, declined, missing, error, and timeout results. They verify the processing boundary in controlled conditions. Real-world usability and the quality of classification require their own evidence. Keep those questions separate when deciding whether the form is ready for customers.

If visitors get stuck after a rejection on your website, tell us where the next step becomes unclear. The email option on that page gives us a place to start an asynchronous conversation about the path you want to improve.

contact formsspam protectionaccessibilitycustomer experience

Ready to turn a workflow into an AI app?

Send the workflow, site, or support problem. We will recommend the smallest useful next step.

Map My AI App