Should the submit button stay disabled until the form is valid?

No, as a default the submit button should stay active and validate on click, explaining what is wrong, rather than sitting disabled until everything is valid. A disabled submit button hides the reason the user cannot proceed, and an unexplained grayed-out button strands people who can see they are stuck but not why. The better default is an enabled button that, when clicked, checks the form and points clearly to the problems, with a truly disabled state reserved for narrow cases where the reason is itself communicated. The popular habit of disabling submit until the form passes every rule trades a moment of apparent tidiness for a user left guessing.

The reasoning starts with what a disabled button actually communicates, which is almost nothing useful. The user sees that they cannot continue but receives no account of which field is at fault, so they are forced to audit their own entries to discover the blocker, and on a long form that audit is exactly the work the button was supposed to help them finish. An enabled button reverses the burden: the click becomes a request for feedback, the form responds by naming the unmet requirements and moving focus to the first one, and the person gets a direct path to completion instead of a silent obstacle. The enabled button does more work for the user precisely because it is allowed to fail loudly and helpfully.

A concrete contrast makes the cost visible. On a multi-section account form, the disabled version grays out submit until every rule passes, and a user who has filled almost everything cannot tell that a single checkbox three sections up is the holdout, so they scan the whole form, give up, and leave. The enabled version keeps submit clickable, and on click it highlights that one unchecked box, scrolls it into view, and shows a short message explaining what is needed. Same validation logic underneath, but one design abandons the user at the threshold while the other walks them the last step. The difference compounds on the cases where the user genuinely believes they are finished, because the disabled button gives them no way to even ask the form what it wants, while the enabled button turns the click into a question and the form into something that answers. The second approach is also kinder to assistive technology, which can struggle to convey why a permanently disabled control is unavailable, whereas a clicked button that announces its errors gives a screen reader something concrete to read aloud.

One case sits outside this: disabling submit is the right call in a few clear, communicated situations. While a submission is in flight, disabling the button prevents a double-charge or duplicate record, and pairing it with a visible loading state explains the wait. A button that triggers a genuinely irreversible or costly action can reasonably stay disabled until a required confirmation is met, provided the missing condition is stated next to it. The unifying rule is that disabling is acceptable when the reason is communicated and the disabled state protects the user, and unacceptable when it merely withholds the explanation they need to proceed.

On your next form, keep the submit button enabled, validate on click, and surface the specific problems by highlighting and focusing the first offending field rather than leaving the user to hunt. Reserve a disabled state for in-flight submissions and clearly explained high-stakes actions, and never let a silent gray button do the job that a clear error message should be doing.