How do I avoid the submit button moving out from under the cursor?

Q: Say there’s a validation error on a form field and you go fix it. But then you immediately go to click the submit button. When you click it, the validation fires, the error is solved, and the page jumps up a bit. Now your cursor is no longer over the button and the click doesn’t register. How do I fix it?

As with most web dev questions, the answer is “it depends”. :D

The problem is that the click event is firing the validation and hiding the error message makes the page move. Let’s examine a few solutions:

Solution 0. You could put a message near the submit button that tells users not to do this. (Don’t do this.) Or you could decide this is a corner case that doesn’t happen frequently enough to worry about, and get back to increasing the performance of the purchase path database queries.

Solution 1. Make the page not move when the error is cleared. E.g. set the error message div to a specific height such that with or without a message it doesn’t change size. Yes, you’ll need to guess the total height and truncate the message if it’s too long. I bet the designers hate this. But I bet you could find a design where the message is brief enough and can be placed carefully enough to make this worth it. “Invalid email format” instead of “Please check the email address and try typing it again or copy and paste the email from your email program.” Another example: the password complexity message. You can show all the rules and a check or x next to each one showing whether this rule is satisfied.

Solution 1a. Make the error message not on the page but on a tool-tip when you hover over it. This is bad because it doesn’t work with mobile or screen readers since neither have a “hover” state. Don’t do this.

Solution 2. Make the error message disappear sooner. Right now you’re checking for validation on blur, and you could check on keyup and on change (type and paste respectively). (And also keep checking on blur, just in case.) Checking on blur is perfect for showing the error, but not great for hiding the error. If the user is mid-way through typing their email the first time and you say their email doesn’t contain an @ and is thus invalid, this is bad. Wait for them to finish typing, and then check. But if they’re mid-way through fixing their email and you hide the error, win! … and now the button is where it should be before they click it.

Solution 3. Make them do something after filling the field before clicking the button. Have them click an “I agree” box or move the commonly errored field earlier in the form. Then by the time they’ve fixed this and then moved to the field that doesn’t error this way, the button has already moved. Yeah, this is likely a long-shot. The designer has legislated the form’s location, and more than likely they clicked “I agree” before they learned they didn’t fill in this field correctly.

Solution 4. Don’t key off the button clicking but rather the form submitting. This may or may not work. The magic sauce is if the button isn’t registering, but the form is, win! The added benefit to this: if they push return in the last field, it submits the form, and they never needed to click the button.

So which solution should you pick? In short it depends. If your design can handle fixed-height errors, this feels like a win. If you can tie into the validation library to run success-checks but not fail-checks on each key press, this feels like a win too. Which solution do you like the best? Or are there other solutions you’ve found?