Let Users Fail Loudly (The Myth of Preventative UX)
A disabled Submit button is not safety; it is a wall with no sign. Let people click, then explain what went wrong and how to fix it.
Disabling Submit because a field is empty does not make the product safe. It makes the product look broken.
A Grey Button Is a Dead End
Setting disabled={true} on Submit is still treated as a mark of professionalism, but it often creates a wall with no sign.
GOV.UK is blunt: disabled buttons have poor contrast, confuse people, and should be rare unless research shows they actually make the interface easier. Almost nobody runs that research. Keyboard users often cannot focus the control, and screen readers may offer no useful explanation. Nielsen Norman’s version is simpler: the control looks like a button, does nothing, and offers no reason. Jakob Nielsen’s work on error messages says the worst error is the one that does not exist. A grey button is that error wearing a suit.
Adam Silver listed the rest in 2023, and the critique has not aged: disabled buttons provide no feedback, look broken when users think they are done, can be hard to see or focus, and may enable outside the viewport without anyone noticing. The form already knows the zip code is missing; the button simply refuses to say so. A nurse, analyst, or shopper reaching the end of a long form concludes that the app is dead, all because you wanted to protect the API from a 400 response you were embarrassed to render.
People Click First and Read Never
People do not read your helper paragraph. They hunt for the brightest action and press it to see what happens. That isn’t a new finding from 2026; it’s how people have used software for as long as there have been buttons.
Preventative UX fights that loop by asking people to reverse-engineer a tooltip, a tiny asterisk, or a banner they have trained themselves to ignore. Most will not. Their natural sequence is to fill in the form, click the action, and respond to what the interface tells them. Grey out the action and you strand them without a next step.
Inline warnings on blur are a close cousin of this mistake. GOV.UK advises against validating as soon as someone leaves a field and recommends waiting until they try to continue. Nielsen’s notes on hostile errors make the same point in different language: premature messages interrupt people who are still working. Catching users mid-thought trains them to fight the form. Letting them trigger the action captures their intent when they are ready, which is the right moment to explain anything wrong with the payload.
The Error Is the Explanation
An error is not a scandal. It is an opportunity for the interface to say clearly what it refused to communicate before.
Nielsen’s ninth heuristic provides the whole method: help people recognize the error, diagnose the problem, and recover from it. Use plain language, identify the precise problem, offer a constructive next step, and present it in a way people will notice. “Error 0x8007000E” fails that test; “Region is required. Pick us-east-1 or us-west-2” passes it. Heuristic 5, error prevention, is real, but teams misuse it to justify disabling the button. Defaults, undo, and confirmation before destructive actions prevent slips. Silence does not prevent a missing zip code; it merely violates heuristic 9 in the name of heuristic 5.
WCAG 3.3.1 is even less romantic. If submission fails, redisplaying the form is not enough. The error must be described in text and tied to the relevant field; color alone is insufficient. Native HTML5 validation can also produce inconsistent copy, unpredictable focus, and messages you cannot style. GOV.UK recommends disabling it with novalidate and providing your own error summary.
Long Forms Need a Map, Not a Wall
Picture a thirty-field clinical form spread across tabs and conditional sections, with a grey Save button at the bottom. After ten minutes of work, the user gets no list, modal, or link to the problem and has to hunt for a red mark. Some people start over; others keep a paper checklist. That analog workaround is part of the product you shipped.
The pattern that works is the one government services already use. Leave Save enabled. If the submitted form is invalid, put an error summary at the top (“There is a problem”), move keyboard focus to it, link each message to its field, repeat the wording beside the input, and prefix the page title with “Error:” so a screen reader announces it immediately. For a dense enterprise form, a modal that lists the problems and links to them applies the same idea. By comparison, “Fix the errors above” in the footer is a riddle delivered after the user has already finished scrolling.
Dead buttons can be even worse on short forms. With nothing else to scan, the whole product feels jammed, so users assume the site is down and leave. WCAG 3.3.3 calls for a correction suggestion when you know the fix, while 3.3.4 calls for preserving the data users entered. Starting them over punishes the click the interface should have answered.
Put the Rules on the Server
A pointer-events: none cage is cheap, but it also suggests that you do not trust the server.
Client-side rules drift, power users and agents bypass them, and JavaScript sometimes fails to load. The API must reject invalid input with a structured 400 response either way. As GOV.UK notes, you always need server-side validation even when you also validate in the browser. Once that protection exists, the frontend can send the user’s intent and render the response. A duplicate client-side state machine is just another thing to forget when the backend adds a flag.
GOV.UK’s data-prevent-double-click addresses a different problem: two accidental submissions. That is not the same as disabling an action until the form is “perfect.” If you are afraid a click will cause a 500 response, fix the server error. A disabled control only disguises the missing check.
Agents Can’t Guess Why a Button Is Grey
A growing share of “users” will not have eyes. Agents encounter the same controls and APIs, but they are even worse than a hurried human at interpreting visual barriers, and they retry much faster.
A grey button communicates no semantic error; it is simply a dead end. A model cannot infer “you forgot region” from opacity. It waits, times out, retries the same payload, and eventually reports that the flow is broken. Give it ERROR_MISSING_FIELD_REGION and it can correct the request. Render that same response as a summary with field links and it also helps the human who would otherwise stare at a disabled Save button.
Preventative UX assumes a person will squint at CSS, while factory automation assumes a machine is waiting for an instruction. You can serve both with one explicit error contract or serve neither with a tasteful visual cage. Heuristic 1 calls for visibility of system status. A grey button hides that status; a named 400 response exposes it.
Trust Comes From Recoverable Mistakes
Wrapping people in happy paths can feel like care, but it often reads as contempt: we do not think you can recover. Teams burn engineering time on state machines that disable, hide, and pre-warn, only for users to click anyway. They always click.
Trust is built after a mistake, when the system names the problem and explains the fix. Coding already works this way through compilers, tests, stack traces, and another attempt. Nielsen’s other warning is to preserve the user’s work, so let people edit what they submitted. Product interfaces that refuse the first click never give that recovery loop a chance to begin.
Enable the action, handle the invalid submission, and put a clear map to every problem at the top of the page. The cheaper frontend is the one that stops simulating a perfect user and starts responding to a real one.