css Archives - Janatha Pulse

21st July 2020

20 mins
3 years
2,882 words
2

Tagged code, css, example, form, html

Best Practices, Do’s and Don’ts of Sign-in Form HTML

If users ever need to sign into your site, good sign-in form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Now more than […]

If users ever need to sign into your site, good sign-in form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Now more than ever, you need to ensure that sign-in isn’t a barrier to using your site. Poorly designed sign-in forms get high bounce rate, and, you know, each bounce means a disgruntled user who’s likely to exit your site, not just a missed sign-in opportunity.

But first, a disclaimer– this post is about best practice for simple sign-in forms that use an email address and password. It doesn’t explain how to use federated log-in with identity providers like Google or Facebook or how to integrate with back-end services.

Reality Check

Do you actually really need users to sign into your site? People don’t like being forced to hand over identity information. And all that personal data and the code that goes with it becomes a cost and a liability for you. If people can use your site without signing in, all the better.

The best sign-in form is no sign-in form at all.

Best Sign-in Form

First up, well formed HTML is the backbone of a good sign-in experience. Use the elements built for the job. They’ve been around for years– form, section, label, and button. You might be tempted to just wrap inputs in a div and handle input data submission purely with JavaScript. Well, don’t do it.

You know, it’s just generally better to use a plain old form element. This makes your site more accessible to screen readers and other assistive devices and helps browsers understand the intention of your code to enable a whole lot of cross-platform, standardized, built-in form features that I’ll show you later.

An HTML form also makes it simpler to build basic functional sign-in for older browsers and to enable sign-in even if JavaScript fails.

Label The Input

Use a label. There are two reasons for that. First reason— a tap or a click on a label moves focus to the input it’s associated with. Second reason— screen readers announce label text when the label or the label’s input gets focus.

You associate a label with an input by giving the label’s for attribute the same value as the input’s ID. Now, placeholders can be useful, but don’t use them as input labels. People are liable to forget what the input was for once they’ve started entering text, especially if they get distracted.

Now, it’s probably best to put your labels above your inputs. This enables consistent design across mobile and desktop, and, according to Google AI research, enables quicker scanning by users. You get full width labels and inputs, and you don’t need to adjust label and input width to fit the label text.

Some sites force users to enter emails or passwords twice. That might reduce errors for a few users, but it causes extra work for all users and can increase abandonment rates. 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.

Use Buttons

Use buttons for buttons. Button elements provide accessible behavior and built-in form submission functionality, and they can easily be styled. There’s no point in using a div or some other element pretending to be a button. Give the Submit button in a sign-up or sign-in form a value that says what it does such as Create Account or Sign In, not Submit or Start or whatever.

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 can add to server load. Conversely, don’t disable form submission awaiting user input.

For example, like, don’t just disable the sign-in button if something’s missing or in the wrong format. Explain to the user what they need to do.

CSS – Size & Padding

The default browser size for just about everything to do with forms is too small, especially on mobile. This might seem obvious, but it’s a common problem with sign-in forms on lots of sites. In particular, the default size and padding for inputs and buttons is too small on desktop and even worse on mobile.

You should add at least about 15 pixels of padding to input elements and buttons for mobile and around 10 px on desktop. But, you know, don’t take my word for it. Try this out with real devices and real humans And also make sure to provide enough space between inputs.

Add enough margin to make inputs work well as touch targets. As a rough guide, that’s about a finger width of margin. You should comfortably be able to tap each of your inputs and buttons without bumping into something else. You also need to make sure your inputs are clearly visible.

The default border styling for inputs makes them hard to see. They’re almost invisible on some platforms such as Chrome for Android. So add a border on a white background. A good general rule is to use, say, #CCC or darker or change the background color instead. I mean, whatever you do, make it blindingly obvious where to tap or click. And remember, design for thumbs.

CSS – Font Size

However, in the real world, most people, many people use their thumbs to interact with phones. Thumbs are bigger than forefingers, and control is less precise. All the more reason for adequately sized touch targets. Now, as with form control dimensions and padding, the default browser font size for input elements and buttons is too small, particularly on mobile.

Browsers on different platforms size fonts somewhat differently, so it’s difficult to specify a particular font size that works well everywhere. A quick survey of popular websites shows sizes of around 13 to 16 px on desktop. Well, matching that physical size is a good minimum for text on mobile. And that means you need to use larger pixel sizes on mobile generally. 16 px on Chrome on desktop is quite legible, but even if you have pretty good vision, it’s difficult to read 16 px text on Chrome on Android.

Lighthouse can help you automate the process of detecting text that’s too small.

Visual Indicators For Validation

Browsers have built-in features to do basic form validation for inputs with a type attribute. Browsers warm when you submit a form with an input value and set focus on the problematic input. You don’t need to use JavaScript. Use the invalid CSS selector to highlight invalid data. This is really widely supported by browsers. And for more recent browsers, you can use not(:placeholder-shown) to avoid selecting inputs with no content.

Attributes

Browsers have multiple helpful built-in features that use input element attributes. Add an autofocus attribute to the first input in your sign-in form. That makes it clear where to start and on desktop at least means users don’t have to select the input to start typing.

Password inputs should, of course, have type=”password” to hide password text and help browsers understand the meaning of the input. Using input type password also means that browsers, such as Firefox, offer to save your password when a form is submitted.

Use input type=”email” to give mobile users an appropriate keyboard and enable basic built-in email address validation by the browser. Again, no JavaScript required. If you need to use a telephone number instead of an email address, input type=”tel” enables a telephone keypad on mobile.

You can also use the inputmode attribute where necessary. inputmode=”numeric” is ideal for pin numbers. But watch out. Using type=”number” adds an up/down arrow to increment numbers. So don’t use it for numbers that aren’t meant to be incremented such as telephone or pin numbers.

Keyboard

If you’re not careful, mobile keyboards may cover your form or, worse, partially obscure the sign-in button. Users may get confused and just give up before realizing what has happened. Avoid this where you can by displaying only the email, phone, and password inputs and the sign-in button at the top of your sign-in page. Put other content below.

Now, I know this won’t be possible for every site. But whatever you do, test on a range of devices for your target audience and adjust accordingly. Some sites, including Amazon and eBay, avoid the problem by asking for email, phone, and password in two stages.

Now, this approach also simplifies the experience. The user is only tasked with one thing at a time.

The Name and Order Complete Attributes

These are a really powerful way for you to help browsers help users by storing data and auto-filling inputs. There are two parts to this. The input name attribute enables browsers to work out the role of various inputs so that they can store email addresses and other data for use with autocomplete.

So don’t make the browser guess. Some browsers, including Firefox, also take note of the ID and type attributes. When the user later accesses a sign-in form on the same site, the autocomplete attribute enables the browser to autofill inputs using the data it stored using the name attribute.

Now, you need different behavior for password inputs in sign-up and sign-in forms. Don’t add autofill to a password input in a sign-up form. The browser may already have a password stored for the site, and auto-filling a password just doesn’t make sense on sign-up, for example, if two people share the same device and one wants to create a new account. Use the appropriate password input name to help the browser differentiate between new and current passwords.

Use name=”new-password” for the password input in a sign-up form and also for the new password in a change password form. This tells the browser that you want it to store a new password for the site. Use name=”current-password” for the password input in a sign-in form or the input for the user’s old password in a change password form. This tells the browser that you want it to use the current password that it has stored for the site.

Different browsers handle email autofill and password suggestions somewhat differently, but the effect is much the same. On Safari 11 and above on desktop, for example, the Password Manager is displayed. And then biometric authentication, fingerprint or facial recognition, is used if available.

Chrome on desktop displays email suggestions depending on what you type, shows the Password Manager, and then autofills the password. Now, here’s another reason to use autocomplete=”new-password”.

Password Generators

Modern browsers suggest a strong password if that’s included for the password input in a sign-up form. Use built-in browser password generators. That means users and developers don’t need to work out what a strong password is. Since browsers can securely store passwords and autofill them as necessary, there’s no need for users to remember or enter passwords and, you know, leave them on sticky notes attached to their computer.

Add the required attribute to both email and password fields. Modern browsers automatically prompt and set focus for missing data. No JavaScript required.

JavaScript

Make sure to add a Show Password icon or text button to enable users to check the text they’ve entered. And don’t forget to add a Forgot Password link. You add a listener to your button, and in the handle, toggle the password input type to text or password. Make sure to include an aria label to warn that the password will be displayed. Otherwise users may inadvertently reveal passwords.

Speaking of accessibility, use aria-describedby to explain password constraints using the element you use to describe your password requirements. Screen readers read the label text, the input type, and then the description. Now, you’ll also want to validate data entry in real time and before submission.

HTML form elements and attributes have built-in features for basic validation, but you should also use JavaScript to do more robust validation while users are entering data and when they attempt to submit the form. Just bear in mind that this does not obviate the need to validate and sanitize data on the back end.

Test And Improve

You need to set goals, measure success, improve your site, and repeat. Usability and lab testing are really helpful for trying out changes. But you’ll also need real-world data to really understand how your users experience your sign-up and sign-in forms with analytics and real user measurement, or monitoring.

And you’ll need to monitor page analytics, including sign-up and sign-in page views, bounce rates, and exits. Make sure to add interaction analytics, such as goal funnels, where do users abandon your sign-up or sign-in flow, and events– you know, what actions do users take when interacting with your forms.

Track Website Performance

Use user-centric field metrics to understand the real experience of real users. Are your sign-up and sign-in forms slow to load? And if so, what is the cause?

Some General Guidelines To Help Reduce sign-in Form Abandonment

Don’t make users hunt for the sign-in. Put a link to the sign-in form at the top of the page using well understood wording like Sign In, Create Account, or Register. And keep it focused.
Sign-in forms are not the place to distract people with offers and features. Minimize complexity.
Ask for other user data, such as addresses or credit card details only when users see a clear benefit from providing that data.
Before users start on your sign-up form, make clear what the value proposition is– you know, how they benefit from signing in.
Give users concrete incentives to complete sign-up. If possible, allow users to identify themselves with a mobile phone number instead of an email address, since that’s the way some users want to do it. They may not want to use their email.
Make it easy for users to reset their password, and make the Forgot Your Password link obvious.
Make sure to link to your terms of service and privacy policy documents and make it clear to users from the start how you safeguard their data.
Include branding for your company or organization on your sign-up and sign-in pages.
Make sure your fonts, styles, and tone of voice match the rest of your site.

Sample Sign-in Form Code

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Sign-in</title>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="stylesheet" href="style.css" />
    <script src="script.js" defer></script>
  </head>
  <body>
    
    <form action="#" method="post">

      <h1>Sign in</h1>

      <section>        
        <label for="email">Email</label>
        <input id="email" name="email" type="email" autocomplete="email" required autofocus>
      </section>
            
      <section>
        <label for="password">Password</label>
        <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
        <input id="password" name="password" type="password" autocomplete="current-password" minlength="8" required>
        <div id="password-constraints">Eight or more characters, with at least one lowercase and one uppercase letter.</div>
      </section>

      <button id="sign-in">Sign in</button>

    </form>
    
  </body>
</html>

script.js

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}


passwordInput.addEventListener('input', resetCustomValidity); 
function resetCustomValidity() {
  passwordInput.setCustomValidity('');
}

// A production site would use more stringent password testing. 
function validatePassword() {
  let message= '';
  if (!/.{8,}/.test(passwordInput.value)) {
		message = 'At least eight characters. ';
  }
	if (!/.*[A-Z].*/.test(passwordInput.value)) {
		message += 'At least one uppercase letter. ';
  }
	if (!/.*[a-z].*/.test(passwordInput.value)) {
		message += 'At least one lowercase letter.';
  }
  passwordInput.setCustomValidity(message);
}

const form = document.querySelector('form');
const signinButton = document.querySelector('button#signin');

form.addEventListener('submit', handleFormSubmission);                       

function handleFormSubmission(event) {
  event.preventDefault();
  validatePassword();
  form.reportValidity();
  if (form.checkValidity() === false) {
  } else {
    // On a production site do form submission.
    alert('Signing in!')
    signinButton.disabled = 'true';
  }
}

style.css

:root {
  --desktop-font-size: 16px;
  --mobile-font-size: 22px;
}

body {
  font-family: sans-serif;
  font-weight: 500;
  margin: 10px 20px;
}

button {
  background-color: #eee;
  border: 1px solid #ccc;
  border-radius: 2px;
  color: #444;
  cursor: pointer;
  display: block;
  font-size: 22px; /* fallback */
  font-size: var(--mobile-font-size);
  font-weight: 500;
  margin: 3px 0 0 0;
  padding: 10px;
}

button:hover {
  background-color: #ccc;
  color: black;
}

button#sign-in {
  margin: 0px 0 0 0;
}

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the password section */
  position: absolute;
  top: -4px;
  right: -2px;
}

div#password-constraints {
  margin: 5px 0 0 0;
  font-size: 16px;
}

form {
  margin: 0 auto;
  max-width: 500px;
}

h1 {
  border-bottom: 1px solid #ccc;
  font-size: 28px;
  font-weight: 600;
  margin: 0 0 20px 0;
  padding: 0 0 5px 0;
}

input {
  border: 1px solid #ccc;
  font-size: 22px; /* fallback */
  font-size: var(--mobile-font-size);
  padding: 15px;
  width: 90%; /* fallback */
  width: calc(100% - 30px); /* full width minus padding */
}

input[type=email]:not(:focus):invalid,
input[type=password]:not(:focus):invalid {
  color: red;
  outline-color: red;
}

label {
  display: block;
  font-size: 20px;
  font-size: var(--mobile-font-size);
  font-weight: 500;
  margin: 0 0 3px 0;
}

form section {
  margin: 0 0 20px 0;
  position: relative; /* for password toggle positioning */
}

@media (min-width: 450px) {
  body {
    margin: 20px 50px;
  }
  button {
    font-size: 14px; /* fallback */
    font-size: var(--desktop-font-size);
  }
  button#sign-in {
    margin: 40px 0 0 0;
  }
  div#password-constraints {
    font-size: 14px;
  }
  h1 {
    font-size: 28px;
    font-size: calc(2 * var(--desktop-font-size));
    font-weight: 500;
    margin: 0 0 80px 0;
  }
  input {
    font-size: 14px; /* fallback */
    font-size: var(--desktop-font-size);
  }
  label {
    font-size: 14px; /* fallback */
    font-size: var(--desktop-font-size);
  }
}

@media (min-width: 800px) {
  body {
    margin: 50px;
  }
}

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Share this: