Webflow Forms • Disable submit button until a form is complete

Hi, Webflowers :wave:t2:

I was thinking about improving UX in my builds, so I started Googling how to disable submit button until all (required) fields/inputs are filled in. Maybe I did a bad research but I did not find a solution — some related stuff yes, though the suggested code is hit a bit different solutions.

Hence, my question: how to do it in Webflow? It is indeed a great UX decision (sometimes at least) to allow users to submit a button until they complete a form.

Thank you I’m advance for the replies!

1 Like

Input fields can be set as required.

The thing is users don’t know which field is required and which is not unless I make it crystal clear in the design — they will know about it only when they click the submit button because a popup will appear stating that they need to fill the required field(s). Moreover, as far as I know, there is no way to customize that popup, but it is not the main point.

In the UX I want to implement in my builds, the solution is quite simple — the form’s submit button is disabled unless all the inputs are completed. Of course, this solution is not for every project, though it is perfect for simple forms.

HI @GeorgyDesign I have created for you very simple example how to validate form that toggle submit button.

The basic principle is that you can check on keyup value length of all elements (input field). If any input field value length is 0 keep button disabled else …

Hope that will help you understand how to

EDIT: feel free to change variables names as I have named these not by convention but for clear understanding.

3 Likes

IMHO, not indicating clearly to the form filler that a field is required is a UX failure. Add a text element that is colored (typically red) that reads “this field is required” offset from the label or the commonly used Splat before the label, is the best design practice. I have conversion data from that proves it. Browsers display a consistent overlay popup on required fields that are unfilled. Users see the same behavior across multiple sites and can easily respond without being alarmed. Not something that should be interfered with.

1 Like

Thanks a ton, Stan! Even more, I’m really thankful for the how-to explanation :smiling_face_with_three_hearts:

I’m still not that knowledgeable in code, so can you clarify where are the variables in your code (I do not see var, so I guess you’ve meant changing classes). Actually, I would be really grateful if you could list all the variables that I need to change and tell me what each variable are responsible for (for example, there is div class="form_w", but I’m not sure if it should be the name of the class of my Webflow Form element.

Again, thank you one more time! :relieved:

Edit: not at home right now, but I’m gonna test your code right away when I come back in Tuesday.

1 Like

I agree and disagree at the same time — UX patterns can be improved and not all the websites have the same form UX design.

I would add that you are right about indicating in the UI which field is required and which is not (I’ve said it in my last reply to you) but we can improve this UX by disabling submit button so the users will explicitly see how they need to complete the form to submit it.

Again, I didn’t take this UX pattern out of nowhere — I’m reading a book about user interfaces and there was that pattern.

If you think you have a better pattern, then make sure you test it. My experience shows hiding the submit button confuses users into thinking the form is broken or is a multipage form that requires much more information, and both of these things create friction which is the last thing I want to do when gathering submissions. A/B Testing and eye tracking testing can provide real answers to how your choices impact users. Just something to consider.

1 Like

Sure, you are right about it. I agree that A/B testing is crucial, especially if uncommon practices take place in the build.

They being said, the UX pattern I want to use is quite common. Moreover, I’m not gonna hide it but disable it — it’s different because disabling means somehow show that the button does not work in the UI. For example, make the button greyed out is a common practice that I’ve seen in this UX pattern. Also, the pointer can be changed to the default one instead of a pointer, so it will be more explicit that the vein doesn’t work.

There is no need to change names for const and/or let variables I only mentioned as I have used eg. inputEl instead common i. As @webdev mentioned good practice is to let visitors know what fields are required. It can be in form of a asterisk ‘*’ next to field label or as text as mentioned alongside form validation warning as tooltips etc…

Indeed, I’m gonna do that in the UI!

I’ll let you know me implementation in Tuesday.

Thanks y’all for the help :blush:

1 Like

Thanks a ton, mate! I’ve just implemented the solution in one of my client’s project and… well, it didn’t work very well because I couldn’t use native Webflow elements due to the inability to use some attributes such as “disabled” (they are reserved by the system), so I did write some custom code with a bunch of tweaks.

I‘ll make a cloneable later, so people can understand how it works.

Hope you are okay with me mentioning that you helped me!

1 Like

Hi again, @Stan!

I’m using two same forms (different classes since, well, they are two separate elements) on a site because the one is static and another one is located in CMS (Collection List).

The thing is they did work together. I’ve tried to debunk what happened, but didn’t find a proper solution.

Maybe you can solve this riddle:

<script>
  function checkform() {
    const formElements = document.forms["wf-form-jobs"].elements;
    let submitBtnActive = true;

    for (let inputEl = 0; inputEl < formElements.length; inputEl++) {
      if (formElements[inputEl].value.length == 0) submitBtnActive = false;
    }

    if (submitBtnActive) {
      document.getElementById("jobs-form-button").disabled = false;
    } else {
      document.getElementById("jobs-form-button").disabled = "disabled";
    }
  };
</script>

<script>
  function checkform() {
    const formElementsCMS = document.forms["wf-form-cms-jobs"].elements;
    let submitBtnActiveCMS = true;

    for (let inputEl = 0; inputEl < formElementsCMS.length; inputEl++) {
      if (formElementsCMS[inputEl].value.length == 0) submitBtnActiveCMS = false;
    }

    if (submitBtnActiveCMS) {
      document.getElementById("jobs-form-cms-button").disabled = false;
    } else {
      document.getElementById("jobs-form-cms-button").disabled = "disabled";
    }
  };
</script>

Please, let me know what’s going on here ;(

P.S: For some, very-very strange reason, only the latter works, e.g., if jobs-form-cms-button is the first, then it won’t work, but jobs-form-button will. And vice versa.

Hi @GeorgyDesign the solution I have provided on CodePen was only a hint how it can be done, but I feel your pain as I pulled my hair to make it work in WF. Most of code that worked outside WF wasn’t working in WF. To make it work I had to redesign code logic. More in video.

Hopefully this will work for you, but not sure about multiple WF forms on one website as I have never done it.

1 Like

Hello @Stan, thanks for your good work on this. I think it’s a really strong UX solution - especially in my case where I have a built a Q and A function with the form and have lots of form fields.

Did you crack the nut on this? If so, would you mind sharing clone so I can inspect the code and classes to get abtter idea of the ser up?

Many thanks!

hi @Dave_Legion I have now checked all demos I have but I cant find it. I have watched video and all you need is in it. What part is you cant make work or you struggle with I can help? But If you will really need I will build it again.

EDIT: Here we go

READ ONLY

1 Like

@Stan, you’re an absolute star!

I was struggling with your theme. It modifies ! == statements and I couldn’t make out what the syntax was. And also whether you go were using #submitbutton ID because you were having issues. That, and copying your code at the likely chance of me incorrectly doing so.

The #submitbutton was missing again in you read-only file haha - I wonder why it keeps rejecting it like that.

Anyway, was great to see your workings on your approach to creating this function. I learnt a lot so thank you for your time and efforts :fist:

Hey @Stan sorry to pester again.

I have a bit of an edge case setup where I am using a form submit button to "mark page as complete’.

I have multiple forms on this page (as a Q&A function) and use your disable/enable code to activate button when each form field is filled.

I’ve tried to adapt your code to trigger the ** "mark page as complete’ button**– so that it is also disabled until #submitbutton is triggered on another form.

I used same class and naming convention, but of course, cannot duplicate ID. I’d appreciate if you have any idea how I might approach this?

HI @Dave_Legion this will need another level of true/false check every time when part of multi stage form is completed. This mean change logic of function(s). Without understanding and seeing structure I can’t give you any reliable response but pure suggestions.

Hey @Stan thank you for coming back to me. I’ve shared with you a basic version of my set up which is hopefully better than trying to explain it.

I thought I might be able to label the second btn with the same classes as the first Btn and target the same ‘disabled’ class. Over-simplistic thinking I know

Your code setup is working, you just need to delete my extra form button for it to work as normal. My attempt is breaking it.

Appreciate any assistance on how I might go about targeting the second button. Thanks, Stan.

https://preview.webflow.com/preview/form-test-e2e876?utm_medium=preview_link&utm_source=designer&utm_content=form-test-e2e876&preview=c468ca2a8bfa5aab64cbecf1dfa40e89&workflow=preview