When a visitor fills in your contact form, quote request or newsletter box, they have already done the hard part. The detected form widget redirect after submission is the moment you decide whether they stay where they are and read a confirmation, or travel to a thank-you page that tells them what happens next. Get it wrong and a completed submission can look like a blank page or, worse, like nothing happened at all.
This guide is for people running an HTML form that already has an action and a method. The Detected Form widget connects that form to WidgetJar so submissions are captured; you keep your own markup and any handler you already rely on. We will cover how to choose between three post-submit behaviours, how to configure each one safely, and how to test the change without breaking the form you already have.
What actually happens when a form is submitted
Before you change anything, it helps to know what the browser is doing. An HTML form is a way to configure an HTTP request. Per the MDN guide to sending and retrieving form data, the action attribute defines where data is sent, while method defines whether it travels as URL parameters (GET) or in the request body (POST). If action is missing, the data goes back to the page containing the form.
That default is one of the reasons the page can appear to "do nothing" — it reloads the same page, and if nothing on that page changes, the visitor sees the form again, empty or not. Any post-submission behaviour you add sits on top of that native flow, so record the baseline first.
Before touching the widget settings:
- Submit the form once and note the URL in the address bar afterwards.
- Open DevTools, go to the Network panel, submit again, and record the request URL, method and status.
- Note whether the page reloads, stays put, or navigates somewhere else.
- Click submit twice quickly and observe what happens the second time.
That record is your before/after comparison. If the widget change produces something different, you can tell what changed and why.
Choose one of three post-submit behaviours
Pick by the goal of the page, not by habit. Here is a working decision table.
| Behaviour | Best for | Watch out for |
|---|---|---|
| Stay on page with a confirmation | Short forms embedded mid-page, newsletter signups, a form beside other content the visitor still needs | Focus must move to the message or screen reader users may never hear it |
| Redirect to a thank-you page | Quote requests, bookings, anything with a next step the visitor should follow | A slow or missing destination page turns success into a dead end |
| Redirect to a download or next step | Lead magnets, gated guides, anything where the visitor expects an asset immediately | Being bounced straight into a file download with no context can feel abrupt |
If the page's job is to collect a request and then hand the visitor off to scheduling, a redirect earns its place. If the form sits inside a longer article or a pricing page, staying put with a clear confirmation is usually kinder — the visitor keeps their place.
Use native validation to stop empty submissions first
There is no point designing a beautiful success state for a form that gets submitted empty. Let the browser do the first pass. Per the MDN documentation on client-side form validation, attributes such as required, type="email", minlength, maxlength and pattern let the browser block submission and show a message when data does not match. That same source is explicit that client-side validation is not a security measure, so your receiving endpoint should validate too.
In practice: mark only the fields you genuinely need as required, use the right type for email and telephone, and label required fields visually. Our walkthrough of the detected form widget required field asterisk explains how to keep the marker and the error text clear, and the guide to HTML form validation for static site contact forms covers the constraints themselves.
Once empty submissions are blocked at the browser level, your post-submit state only fires for real attempts.
Write a stay-on-page confirmation that people notice
Staying on the page is the least disruptive option, but it only works if the confirmation is both visible and announced.
What to say: one short sentence confirming receipt, one sentence setting expectations. For example: "Thanks — your request is in. We reply within one working day." Avoid vague "Success!" alone; it tells the visitor nothing about what happens next.
Where to put it: at or near the top of the form area, in the same visual region the visitor was just interacting with. Do not append it below the fold.
How to move focus: this is the part most implementations miss. If the message appears visually but focus stays wherever it was, a screen reader user may never know anything happened. Move focus to a static element at the start of the confirmation using tabindex="-1". The W3C modal dialog pattern documents this technique for dialogs — placing tabindex="-1" on a static element and focusing it so assistive technology reads the content in order — and the same reasoning applies to an inline confirmation. If your confirmation is a popup rather than inline text, run the checks in our accessible popup keyboard and focus checklist.
A minimal inline pattern, assuming your own markup for the message container:
<div id="form-status" role="status" tabindex="-1" hidden>
Thanks — your request is in. We reply within one working day.
</div>
Show the element, then call .focus() on it once the submission is confirmed. role="status" gives polite announcement for many screen readers; the explicit focus move makes the message discoverable regardless.
If you redirect, treat the destination as part of the form
A thank-you page is a real page. It needs a fast load, a clear heading that confirms what happened, and a pointer to the next step. Keep it on the same domain so it feels continuous, and if you also want it indexed, make sure it has its own purpose rather than being an empty duplicate of the form page.
Two practical points:
- Test the destination URL by opening it directly. If it 404s or redirects again, your visitors land somewhere wrong after doing everything right.
- Avoid chaining redirects. A redirect that triggers another redirect is where loops come from. If the destination itself redirects, fix that first.
If your thank-you page is where you offer a download, put the download link in plain text on the page as well as starting any automatic download, so visitors who dismiss the file dialog can still find it.
Consent and data notes before you flip the switch
Changing what happens after submission also changes what visitors understand they have agreed to. Two things are worth confirming:
- If you collect personal details, make sure a consent checkbox is present and required where your policy needs it. Our guide to adding a consent checkbox to an existing form covers how the Detected Form widget handles this without you rewriting the form.
- Keep sensitive fields out. Passwords and card details do not belong in a form that is connected to a third-party widget.
Neither step is a substitute for legal advice; check your own obligations for the jurisdiction you operate in.
A test script you can run in ten minutes
Run this every time you change post-submit behaviour, on desktop and on a real phone.
- Baseline check. Submit the form and confirm the request still appears in the Network panel with the method you recorded earlier. This proves the original handler still receives submissions.
- Keyboard-only submit. Tab through the form, press Enter or Space on the submit button, and confirm every field can be reached in order.
- Confirmation check. After submitting, confirm you can see the confirmation or arrive at the destination page. With a screen reader or the browser's accessibility tree, confirm the confirmation text is read.
- Focus check. Verify focus moved to the confirmation (or the destination page's heading) rather than remaining on the submit button.
- Double-submit. Click submit twice quickly. The second click should not create a confusing second state or a duplicate-looking page.
- Back button. After a redirect, press Back. The visitor should be able to return to the form page. Note whether the form is empty; that is expected in most browsers and worth mentioning if you show a message.
- Mobile view. Repeat the keyboard check with a mobile viewport, especially if the confirmation appears above the visible area after submission.
If you also add spam protection, run the checks in our honeypot guide for existing HTML forms alongside this script, since bot-blocking logic can interact with validation and submission handling.
Common failure modes and how to isolate them
The form submits but nothing happens. Compare against your baseline request. If the request still goes out but no confirmation appears, the issue is in the confirmation display or focus logic rather than the form itself. Check whether your own submit handler calls preventDefault() and never re-enables the post-submit state.
Focus never leaves the submit button. Confirm the message element actually receives .focus() and has tabindex="-1". If it is hidden when you focus it, focus will fail.
Redirect loops. Open the destination URL directly. If it redirects somewhere else, fix the destination rather than the form.
Fields that never reach your endpoint. If the form's fields stop arriving at the address in its action, something is intercepting the submit. Disable other scripts on the page one at a time to find the culprit before changing widget settings.
A confirmation that sounds like a new page load. If you redirect but the destination is a bare page with no heading, screen reader users hear nothing useful. Give it a visible <h1> and, if you control it, move focus to it with tabindex="-1".
The takeaway
Post-submission behaviour is part of the form, not an afterthought. Pick the pattern that matches the page goal, let native validation weed out empty attempts, move focus so confirmations are heard, and re-run the baseline request every time you change something. The visitor did the work; the next screen should prove it counted.
Ready to set this up on a form you already have? Configure the post-submit behaviour and connect your HTML form through the Detected Form widget, then install the embed script on your registered domain and run the test script above before you announce the change.