Form validation error: find the rule at fault

A rule written for one example rejects everyone who types something else. An email check that forbids a plus sign turns away someone who uses a plus address to sort their mail. A phone field that accepts digits only rejects a number with a space after the country code, which is a common way to write it on a phone. A name field that needs two words rejects a single name, and a surname with an apostrophe fails a rule that allows letters only. The owner tests with a clean address and a clean number, so the form looks correct from the inside.

• Type a plus address, a number with spaces, and a single name, and note which entry the form rejects.
• Look at the field in the Elements panel for a pattern attribute or a validation function.
• Add a trailing space to a value that passes, then submit it. A failure means the value is not trimmed.
• On submit, open the Network tab and read the response body for a field name and a rule.
• Compare the message in Chrome and in Safari, since the browser's own wording differs by browser.

The four entries on this list are common, and each one breaks a different kind of rule. A plus sign in an email address is valid under the email standard, but some forms still treat it as an error because a rule copied from an old example never allowed one. A phone field that allows digits only fails on spaces, on a leading plus and on dashes. A name field that requires a space fails a single name, and a letter-only rule fails an apostrophe. A form that passes the owner's clean sample usually has rules written for that sample alone.

Start by finding where the message comes from. A message that appears while you type, or as soon as you leave a field, came from the page's own script, so look for a pattern attribute or a validation function on that input in the Elements panel. A pattern attribute is checked by the browser before the form is sent, and the wording belongs to the browser, so the same entry can get different text in Chrome and in Safari.

A message that appears only after Send can come from the browser's check on submit or from the server. Open the Network tab, press Send, and read the response. A 400 or 422 status whose body names a field means the server rejected what the page sent, so fixing the page alone changes nothing. A trailing space is a separate cause. Phone keyboards can add a space after an autocomplete suggestion, and a rule that does not trim the value fails on it. Add a space to a value you know is valid, submit it, and watch whether the message changes.

Make a short list before you test: a plus address, a phone number with spaces and a country code, a name with an apostrophe, a single name, and a value with a trailing space. Send each one through the form and note which message appears and beside which field. A simulated visitor types these entries on a phone-width browser, reads the message the form shows, and reports the step where it stopped, with a screenshot of the message beside its field. That gives you the exact text a stranger has to act on, which is the part a fix has to change.

A new country on the phone list, a stricter email check or a field added later can reject entries that passed last month. Rerun the same short list after each change to a rule, and let the GitHub Action run it on each preview deploy. With paid credits, visitors can reach a protected preview through a site password or a preview bypass, so the check does not wait until the page is public.