Enquiry forms are often the main way a Dubai business website turns a visitor into a conversation. When the form rejects input, the way it explains the problem matters: a vague red outline or a message that disappears is easy to miss, especially for keyboard and assistive-technology users.

This article walks through a small prototype we built to study one pattern: an error summary at the top of the form, inline messages tied to each field, and validation driven by the browser's native Constraint Validation API. The live code is on CodePen: Accessible enquiry form validation (no data sent).

Scope first. This is a local, client-side UI study, not a production enquiry form. There is no backend. The demo’s own form code does not submit entered values, make network requests or write to browser storage. It is an original interface concept, not client work, and the sample values shown in its placeholders (such as "Layla Example") are fictitious.

The markup: native constraints plus described-by links

The form has four fields: full name, email, project type and project details. Each field uses the native HTML constraints that apply to it: all four are required, the email field uses type="email", and the name and details fields use minlength. The form has novalidate, so the browser's own error bubbles are suppressed and the script can present messages consistently.

Each control points at its hint and error elements with aria-describedby:

<input id="email" name="email" type="email" autocomplete="off" required
  placeholder="e.g. layla@example.com" aria-describedby="email-hint email-error">
<p class="hint" id="email-hint">Use the format name@example.com.</p>
<p class="error" id="email-error"></p>

As MDN's aria-describedby reference explains, the attribute takes a space-separated list of IDs in the same document, and the referenced text acts as a description of the control. Here that means the format hint and the current error message are both associated with the field. The error paragraph starts empty; the hint is available immediately, and error text is added when a problem is found.

Turning ValidityState into readable messages

Rather than writing custom regular expressions, the script reads each element's validity object. MDN's ValidityState page lists the boolean flags; this demo only needs three of them: valueMissing, typeMismatch and tooShort.

function messageFor(el) {
  const v = el.validity;
  const label = form.querySelector(`label[for="${el.id}"]`).textContent;
  if (v.valueMissing) return el.tagName === 'SELECT' ? `Choose a ${label.toLowerCase()}.` : `Enter your ${label.toLowerCase()}.`;
  if (v.typeMismatch) return 'Enter an email address like name@example.com.';
  // minlength is only enforced natively after user edits, so check length explicitly too.
  if (v.tooShort || (el.minLength > 0 && el.value.trim().length < el.minLength)) return `${label}: use at least ${el.minLength} characters (now ${el.value.trim().length}).`;
  return '';
}

Two details are worth noting. The message text is built from the visible <label>, so the wording in the summary matches what users see on screen. And native minlength validation does not cover values assigned by JavaScript, so the demo also checks the trimmed length explicitly (see MDN's guide to constraint validation). The message also reports the current character count, which tells the user how far off they are.

A separate check() function writes the message into the field's error element and sets aria-invalid to "true" or "false". Fields are re-checked on blur (when they contain a value) and on input once they are already marked invalid, so a message clears as soon as the problem is fixed instead of waiting for another submit.

The error summary and focus

On submit, the script calls preventDefault(), checks every field and collects the failures. If there are any, it builds a list of links inside a summary container that has tabindex="-1" and a heading ("Please fix the following"):

• each link's href points at the field's ID, and its click handler calls el.focus() on that field directly;
• the summary is un-hidden and the script calls summary.focus();
• a status paragraph with role="status" and aria-live="polite" is updated with a count, for example "4 problems found. Nothing was sent."

The intent is that keyboard and screen-reader users land on a single list of problems and can jump from each item to the field that needs attention. We should be clear about what has been checked: the focus behaviour is described here from the code. We have not manually tested focus movement in a range of browsers or with screen readers, and this article is not an accessibility audit.

In a check with an empty form in a browser, the summary listed four errors, each linked to its field. With valid fictitious values, the status line reads exactly: "Validation passed. This is a demo, so nothing was sent or stored."

A deliberately disabled submit button

The submit button is rendered with disabled, and the last line of the script enables it, after all handlers are registered. If JavaScript is unavailable, or if anything earlier in the script throws, the button stays disabled and a <noscript> note explains why.

That helps prevent accidental submission during ordinary use of this local demo. It is not a pattern we would recommend for a live enquiry form. A real form should still submit, and still be validated, when client-side scripts fail.

What production would still need

Client-side validation improves the experience, but it is not a security measure: anyone can bypass it. A real enquiry form also needs server-side validation of every field, spam and abuse protection, secure handling and storage of personal data, clear server error and success states, and reliable delivery to whoever answers enquiries. None of that is implemented in this prototype.

Feel free to fork the CodePen and adapt the summary pattern to your own forms. If you are planning a website or enquiry form for a business in Dubai and would like help, you can send an enquiry through the Nordvia Digital contact form.