You've checked the submit handler. You've checked the network tab. People are clearly reaching the form, filling it out, clicking the button — and nothing happens. No error message. No redirect. Just a dead button.
This is one of the most disorienting conversion problems to debug because the symptom looks like a JavaScript crash, but the cause is pure HTML.
How HTML5 validation handles hidden fields
When a browser processes a form submission, it runs native validation against every field marked with the required attribute — visible or not. It doesn't check whether the field is on-screen. It doesn't care if it's hidden with display: none or visibility: hidden. If a required field has no value, validation fails and the submit is blocked.
The problem is that browsers try to surface the error by scrolling to the offending field and showing a tooltip. But if the field is hidden, there's nothing to scroll to and nothing to show. The browser swallows the error silently, and from the user's perspective the form just... doesn't work.
This is a documented bug pattern in plugins and form builders that use conditional logic. A real example from the custom-contact-forms GitHub repo describes it exactly: "It will not show any error since the field that have an error on it is hidden so it simply looks as form Submit is not working." The plugin was hiding fields with a .field-hide CSS class but leaving the required attribute intact.
Where conditional logic goes wrong
Most form builders let you configure logic like "show this field only if the user selects option X." When the condition isn't met, the field gets hidden. The bug: many builders hide the field visually but don't touch the required attribute or set the field to disabled.
Two approaches actually fix this at the code level:
- Remove the
requiredattribute when hiding the field - Set the field to
disabledwhen hiding it — browsers skip disabled fields entirely during validation
That second option is usually safer because disabled fields are excluded from both validation and form serialization, so you don't accidentally submit blank values.
If you're working with a no-code form builder (Webflow, HubSpot, Typeform native embeds), the fix is usually in the conditional logic settings rather than the HTML — check whether the builder has an option to "skip validation for hidden fields" or similar.
Finding the broken session in session replay
The hard part isn't fixing it once you know which field it is. The hard part is finding it.
Start by filtering your session replay recordings for sessions where someone attempted a form submission but never completed it. In CloseTrace, the specific filter to use is: sessions with a form_submit_attempt event and zero form_submit_success events on the same page. That segment will be small — maybe a dozen sessions — and almost every one will show the same pattern: fill, click, nothing.
Watch two or three of those recordings. You'll see exactly where the tap or click lands, whether the button had focus, and whether any other UI changed after the click. In most cases you'll see the button depress visually (or animate) but the form doesn't move. That's the validation block. There's no redirect, no loading state, no error — just the form sitting there.
Once you've confirmed the symptom in replay, go back to the form builder or inspect the form's DOM in the recording. Look for fields that are hidden when the affected users filled out the form. Cross-reference those against fields that have required set.
One caveat worth naming
Session replay tells you the form is broken and approximately when in the interaction it fails. It doesn't automatically identify which hidden field is the culprit — that still requires a DOM inspection step or digging through your form builder's conditional logic configuration. Think of replay as the evidence that confirms you have the problem; the field-level diagnosis is a separate step.
If you're dealing with a complex multi-step form or a form with a lot of conditional branches, it helps to combine replay with funnel data to narrow down which user paths trigger the block. Not every branch of the form will have the bug — usually it's one specific conditional path where a field gets hidden while staying required.
This is also worth checking on mobile separately. Some form builders apply conditional logic differently across breakpoints, and a field that renders correctly on desktop might stay visible (and empty) on mobile. See find mobile-only website bugs your QA never catches for the replay workflow there.
What to do right now
Pull up your session recordings and filter for form_submit_attempt + no conversion on any high-traffic landing page you're running paid traffic to. Watch five sessions. If you see submit clicks with no response, you've likely got a hidden required field somewhere in that form's conditional logic.
The file slug for this post should be: hidden-required-field-blocking-form-submit.mdx