A Launch Checklist for Reliable Enquiry Forms on Dubai Business Websites

For many small-business websites in Dubai, the enquiry form is the main reason the site exists. When it quietly fails, nobody notices for weeks. This checklist covers the dull parts that decide whether an enquiry actually reaches a person.

1. Start with a form that works without JavaScript

Build the plain HTML version first. If your script fails to load, the form should still submit as a normal POST. This snippet is illustrative, not production code, and the endpoint is a placeholder:

<form action="/enquiry" method="post">
  <div role="alert" id="form-errors" hidden></div>

  <p>
    <label for="name">Name (required)</label>
    <input id="name" name="name" type="text"
           autocomplete="name" required maxlength="100">
  </p>

  <p>
    <label for="email">Email (required)</label>
    <input id="email" name="email" type="email"
           autocomplete="email" required maxlength="254">
  </p>

  <p>
    <label for="enquiry">Your enquiry (required)</label>
    <textarea id="enquiry" name="enquiry" rows="6"
              required maxlength="3000"></textarea>
  </p>

  <button type="submit">Send enquiry</button>
</form>

A few details matter here:

• Every control has a visible <label> linked by for/id, and a name so the server receives the value.
• Required fields say "required" in text, not only with colour or an asterisk.
• Native validation stays on, so the form still gives feedback without JavaScript. Add novalidate only once your script actually renders accessible replacement errors.
• Don't restrict names to Latin letters. Customers may type their name in Arabic or another script.

2. Validate again on the server

Client-side checks help users, but they are easy to bypass (MDN: client-side form validation). The server has to repeat every rule, whatever the browser does:

• Trim the values, then reject empty required fields.
• Enforce the same maximum lengths as the HTML.
• Check the email format sensibly, without a giant regex.
• Treat the enquiry text as untrusted and escape it wherever it is shown, including notification emails.

3. Make success and failure explicit

The server should return one of three clear outcomes:

1. Validation error. Re-render the form with the input kept, an error summary and a message next to each field.
2. Accepted. Show "Thanks, we've received your enquiry" once it has been stored or queued. If the notification email then fails, the enquiry is still accepted: retry and alert internally instead of telling the customer it wasn't sent.
3. Server failure. If storage itself failed, say plainly that the enquiry was not received. If the outcome is uncertain (for example, a timeout), say you couldn't confirm it rather than claiming it failed, and show another way to get in touch.

If you enhance the form with fetch(), keep the same contract and read the response body, not just the status code. An HTTP 200 from a misconfigured handler does not mean the enquiry reached anyone.

4. Make errors accessible

Following the W3C WAI forms tutorial on user notification: for server-rendered errors, put the error count in the page <title> and main heading. In the summary, name each field by its label, explain the fix, and link to the field.

For script-rendered errors, put the summary in a container with role="alert". Connect each message to its input with aria-describedby, mark the input with aria-invalid="true", and move focus to the summary or the first invalid field. Write messages that say what to do, not just "Invalid".

5. Add spam protection in layers

No single technique stops all spam, and a CAPTCHA is not a guarantee: it adds friction for people and bots can still get through. Layer defences:

• A honeypot field hidden from sighted users, screen readers and keyboard focus, with autocomplete="off" and a neutral name, to discourage accidental completion; test it with assistive technology and password managers.
• A minimum time between page load and submission, checked on the server.
• Rate limiting per IP address and per email address.
• Simple content checks, such as link-only messages.

Autofill users can submit quickly, and many people can share one office or mobile-carrier IP address. Keep thresholds generous, prefer soft responses such as a delay or extra review over hard denial, and log rejections with a reason code so you can tune rules that block real customers.

6. Test real delivery before launch

"The button worked" proves very little. Before launch:

• Test both the HTML-only and JavaScript paths, on mobile and desktop.
• Confirm each arrives in the inbox the business actually reads, including checking spam folders.
• Store every enquiry before sending the notification email, so a delivery failure doesn't lose the lead.

7. Track conversions honestly and privately

Fire the "enquiry submitted" event only after the server confirms acceptance, never on the button click or the error page.

Keep personal data out of analytics, as Google Analytics' PII guidance requires. Don't send names, email addresses or enquiry text in event parameters, page titles or URLs such as /thanks?email=.... The event only needs to record that an enquiry happened.

Launch checklist

• [ ] Works with JavaScript disabled
• [ ] Visible labels, name attributes, required fields marked in text
• [ ] Server-side validation that mirrors the client rules
• [ ] Separate validation-error, accepted and server-failure states
• [ ] Accessible error summary and inline messages
• [ ] Honeypot, timing check and rate limits, with logged rejections
• [ ] Real enquiries arrive in the business's inbox and are stored first
• [ ] Analytics event fires only after acceptance, with no personal data

Author note: Nordvia Digital is a web design and SEO company based in Dubai.