Testing Web Forms: A Checklist for Catching Broken Submissions

A form is the one part of most websites where a stranger actually has to trust you enough to type something in and click submit. Most site audits check things a visitor never consciously notices - load time, meta tags, contrast ratios - while the one interaction that directly costs you money when it breaks, a checkout or a signup form, often only gets tested by whoever built it, once, on their own machine.

Validation Behavior

Client-side validation (the instant red border when an email field is malformed) is a UX nicety, not security, and it's trivial to bypass by disabling JavaScript or editing the request directly. The question worth testing isn't whether the friendly inline error shows up - it's whether the server rejects the same bad input when the client-side check is skipped entirely. A form that only validates in the browser will silently accept garbage the moment JavaScript fails to load, which happens more often in production than most teams assume - ad blockers, corporate proxies that strip scripts, and slow connections that time out a script tag all produce a form with no client-side validation at all, submitting straight to whatever the server will accept.

Error State Testing

• Visibility. Is the error actually visible without scrolling, or does it appear above the fold while the field with the problem is below it?
• Screen reader announcement. A red border and a color change communicate nothing to someone using a screen reader. An error needs to be programmatically associated with its field (via aria-describedby) or announced through an aria-live region for it to register at all.
• Clears on correction.An error that stays visible after the user has already fixed the problem creates a form that looks permanently broken even when it isn't.
• Inline vs. summary.Long forms benefit from both - inline errors at the field and a summary at the top listing everything that needs attention, since a user who submits a 12-field form with 3 errors shouldn't have to scroll through the whole thing hunting for red text.

Autofill and Input Types

Setting the correct type attribute (email, tel, number) isn't cosmetic - it changes which keyboard a mobile visitor gets, directly affecting how easy the field is to fill in correctly. Correct autocomplete attributes (name, email, street-address) are what let a browser's or password manager's autofill work at all - worth testing explicitly, since a custom-styled input built without these can look fine visually while quietly breaking autofill for a large share of visitors who rely on it.

Submission Edge Cases

• Double-click, double-submit.A submit button that isn't disabled the instant it's clicked can fire twice - two orders, two account creations, two support tickets from one impatient click.
• Mid-submit network failure. What does the form show if the connection drops between click and response? A spinner that never resolves is a worse experience than a clear error asking the user to retry.
• Server-side failure (500). Does the form show a real error, or does a generic catch-all leave the user staring at a blank page with no idea whether their submission went through?
• Post-submit behavior. Redirecting after a successful submit prevents a refresh from resubmitting the form - staying on the same page without clearing it invites exactly that.

The Silent Failure Audits Miss

The most dangerous form bug is the one that throws no error at all. A backend refactor that changes an endpoint path, a form actionattribute left pointing at a URL that now 404s, a serverless function that silently times out - none of these produce a visible JavaScript error or a broken-looking page. The form still renders, the button still submits, the user still sees a generic "thank you" message if that's hardcoded into the client rather than driven by an actual server response - and every submission from that point on goes nowhere. This is exactly the class of failure that only shows up by actually testing an end-to-end submission on a schedule, not by eyeballing the page.

Our browser test crawls real pages and flags forms with broken actions, missing labels, and console errors thrown during interaction - the category of failure that's invisible until a real visitor hits it. See our guide to finding broken links and JS errors for the related class of silent failures that show up in navigation rather than forms.