Forms that declare native HTML constraints produce fewer server-side validation rejections per submission than forms validated only in custom JavaScript

Hypothesis

Server-side validation is mandatory; client-side validation exists so that most submissions never trigger it. There are two ways to provide the client side: native constraint attributes on the controls (required, type, pattern, min, max, maxlength), which the browser checks before an interactive submission, or custom script that inspects values and blocks the submit event. MDN's guide to constraint validation describes the native mechanism and its edges: a novalidate attribute on the form disables interactive validation, and calling the form's submit() method sends the form data to the server even if it doesn't satisfy the constraints. A common pattern is custom validation written for styling and messages, with the native attributes dropped along the way. The hypothesis is that forms whose native attributes mirror the server's rules produce fewer server-side rejections per submission than forms validated only by script, and that the difference comes mostly from sessions in which the script did not run: it failed to load, threw before attaching its handlers, or missed autofill and paste paths.

Prediction

In an A/B comparison of the same form with and without native constraint attributes, both variants keeping the same custom script and server rules, the variant with native attributes shows a lower rate of server-side validation rejections per submission. The gap is concentrated in sessions with a script error or without the script's readiness marker, and near zero where the script ran; the rejection categories that shrink are those the native attributes can express (missing required fields, malformed email, out-of-range numbers), not cross-field rules. If the rejection rates are equal, or the gap is not concentrated in script-failure sessions, the hypothesis is false.

Proposed test

1. Pick a public form with a few thousand submissions a month and a server that returns structured validation errors by field.
2. Build variant A with native attributes matching the server rules field by field and variant B with the attributes removed; keep script, layout and messages identical. Assign visitors by a stable hash.
3. Add a hidden field the script sets when its handlers attach, so that the server can tell whether the script ran; log script errors with the variant.
4. For four weeks, record per submission: variant, script-ran marker, rejection (yes or no) and the rejected fields with their rule categories.
5. Compare rejection rates per variant overall and split by the marker; report counts and intervals, and list the rule categories that differ.

Status

No result is claimed. If the script is reliable and the audience's browsers rarely fail to run it, the difference may be too small to measure in four weeks; that result would itself say how much the native layer adds for that audience.