Submit button not working on website: find why

The visitor presses the button and the screen does not move. No message appears, no spinner shows, and no new page loads. The cause could be a disabled button that looks enabled, a transparent layer from a banner or chat widget sitting over the button, a button placed outside the form it is meant to send, or a script that failed before the press did anything. Each one looks the same to the visitor. An owner who presses with a mouse on a large screen often gets through, because the owner's session is in a different state.

• Does Tab move focus to the button, and does Enter or Space send the form when the mouse press does nothing?
• Does the button still carry a disabled attribute in the Elements tab after every required box is ticked?
• Does a cookie banner, chat bubble or sticky bar sit over the button at phone width?
• Does the button sit inside the form element, or name the form with a form attribute?
• Does the console show an error on the press, or a request left pending from an earlier try?

Tab to the button and press Enter or Space. If the form sends, the button's own logic works, and the mouse or finger press is being taken by something else, such as a layer on top of the button or a target smaller than it looks. If the keyboard press also does nothing, the fault is in the button or the code behind it, and a covering layer is not the cause. This one test splits the two families of cause.

To find the layer, right-click the spot where the button sits at phone width, choose Inspect, and read the element the browser selects. A cookie banner, a chat widget or a sticky header above the button shows up by its name or class. It is easy to miss on a desktop, because the layer may appear only at phone width or after a short delay.

A disabled attribute stays on a button after a failed try if the script that turns it back on never ran. Read the button in the Elements tab after the last box is ticked, and check the attribute. A button marked as a plain button, or placed outside the form element with no form attribute, sends nothing on press even when it looks right, because it is not a submit control for that form.

Some forms hide a verification token behind a widget. If the widget never loads, because a privacy setting or a blocked script stopped it, the token stays empty and the submit handler returns without a word. The console usually shows the blocked script. Check that the widget is visible and its script loads on the form page before you change the handler.

A press is handled by a script. If an error earlier on the page stopped that script before it attached the click handler, the press does nothing, and the console shows the error as the page loads. A press can also do nothing on a second try, when a first request is still waiting for a reply and the handler holds the button in a sending state. The Network tab shows that request as pending, with no response.

A simulated visitor records what the browser saw at each step: the press, any relevant JavaScript error, failed or slow app requests, and a screenshot of the button. The report puts each one on its step, so a slow request from an earlier try shows up beside the press. It cannot tell you whether a real visitor on another phone would hit the same layer, so check the layer on the phones your visitors use. For the full pre-launch pass, see the guide to testing a website before launch.

Test a website before launch

A new cookie banner, a chat widget or a redesigned footer can cover the submit button again, and it can do so only at phone width. Rerun the same visitor after each design, script or form change, on a phone and a laptop, and compare where the press lands. Owners also test behind a site password and check each preview deploy before it goes live.