Help password managers understand that a form has been submitted. There are two ways to do that:
With an XMLHttpRequest or fetch request, make sure that sign-in success is reported in the response and handled by taking the form out of the DOM as well as indicating success to the user. Consider disabling the Sign in button once the user has tapped or clicked it. Many users click buttons multiple times even on sites that are fast and responsive. That slows down interactions and adds to server load. Conversely, don’t disable form submission awaiting user input. For example, don’t disable the Sign in button if users haven’t entered their customer PIN. Users may miss out something in the form, then try repeatedly tapping the (disabled) Sign in button and think it’s not working. At the very least, if you must disable form submission, explain to the user what’s missing when they click on the disabled button. Caution: The default type for a button in a form is submit. If you want to add another button in a form (for Show password, for example) add type=”button”. Otherwise clicking or tapping on it will submit the form.
Some sites force users to enter emails or passwords twice. That might reduce errors for a few users, but causes extra work for all users, and increases abandonment rates. Asking twice also makes no sense where browsers autofill email addresses or suggest strong passwords. It’s better to enable users to confirm their email address (you’ll need to do that anyway) and make it easy for them to reset their password if necessary.
This is where the magic really happens! Browsers have multiple helpful built-in features that use input element attributes.
Autofocus provides clear visual focus on desktop.
Password input from the Google sign-in form: with Show password icon and Forgot password link.
Unfortunately, if you’re not careful, mobile keyboards may cover your form or, worse, partially obstruct the Sign in button. Users may give up before realizing what has happened.
The Sign in button: now you see it, now you don’t. Where possible, avoid this by displaying only the email/phone and password inputs and Sign in button at the top of your sign-in page. Put other content below.
The keyboard doesn’t obstruct the Sign in button.
You’ll need to test on a range of devices for your target audience, and adjust accordingly. BrowserStack enables free testing for open source projects on a range of real devices and browsers.
The Sign in button: obscured on iPhone 7 and 8, but not on iPhone 11.
Some sites (including Amazon and eBay) avoid the problem by asking for email/phone and password on two pages. This approach also simplifies the experience: the user is only tasked with one thing at a time.