Use cross-platform browser capabilities to build secure, frictionless, and easy-to-use login forms

Web. Dev /sign-in-for… Author: Sam Dutton Portions of this page are modifications based on work created and shared by Google and used according to Terms described in the Creative Commons 4.0 Attribution License.

Under the Creative Commons Attribution 4.0 License, it should be noted that the translation below does not fully reflect the author’s original intention and that there may be some variation in the Attribution depending on the situation

By:

The landing page is often one of the first pages a user touches when using our page. For this reason, a good landing page is essential to improve the user experience and keep users using our products. I believe you all have experience of not using the corresponding product because of frustration in the registration or login process and experience. While not necessarily applicable to every situation, hopefully some of the best practices mentioned in this article will help you create a better user experience.

For those who like to watch videos, the article also has a corresponding video.

Body:

A good login form is essential whenever a user needs to log into your site. This is especially true for people who have poor Internet access, use mobile phones, and log on in emergencies or under pressure. A poorly designed form often results in a high pop-up rate. And every popup could mean a lost and disgruntled user — not just a failed login.

Try it! If you want to get your hands on these best practices, take a look at the Login form best practice codelab.

The link is to a login form that practices all the best practices: sign-in form.glitch.me

Check List

  • Using semantic HTML elements:<form>.<input>.<label>, and<button>.
  • use<label>To label the input field
  • Use the attributes of the element to use the browser’s built-in features:type.name.autocomplete.rquired.autofocus.
  • For the input boxname 和 idProperty sets a value that does not change between loads or releases
  • Place parts of the login component in your ownformThe element
  • Ensure that the form submission action succeeds
  • Used for the password entry box in the registration form or reset password pageautocomplete="new-password"
  • Used in the password box on the login pageAutocomplete = "current password"
  • Provides the password display function.
  • Used for the password entry boxaria-label 和 aria-desribedby
  • Don’t force the user to type twice
  • Design forms so that input fields or buttons are not obscured by the phone’s keyboard
  • Make the form usable on the phone: use a recognizable font, and make sure the input fields and buttons are size that the user can touch
  • Maintain brand tone and style for your sign-up and login interface
  • Test your forms in development testing and on the user side: add page analysis, interaction analysis, and user-centric performance testing to your sign-up and login flows
  • Test your pages on different browsers and machines: The behavior of forms often differs dramatically from platform to platform

Use HTML that makes sense

Use elements designed for the corresponding function:

,

use<form>

You might be tempted to put the input box in

and upload the input data entirely in JavaScript. In most cases, it’s better to use an old friend

. This will make your pages more user-friendly to screen readers or other assistive devices, enable a number of browser-built features, make it easier to adapt to older browsers, and make your pages work without JavaScript.

Ah, I see!

A common mistake is wrapping the entire web page in a form, which can cause problems with the browser password manager and auto-complete. Use a different one for each component that requires a form

use<label>

Use 

<label for="Email">Email</label>
<input id="Email"... >
Copy the code

There are two reasons for this:

  • Touching label moves focus to the appropriate input box. Through the use offorProperty and inputname 和 idTo associate the corresponding input and label.
  • When the focus moves to the label or corresponding input, the screen reader reads the corresponding label

Don’t replace labels with placeholder. Because when people start typing, they tend to forget what they’re typing, especially if they’re distracted (hey, am I typing in an address or a phone number or my user ID). There’s also a lot of downside to using placeholder, so if you’re not convinced that using placeholder properties and placeholder in form items is bad for you, look at the following two articles

It is best to place label above input. This helps maintain a unified design between mobile and desktop, and Google AI Research has shown that this will allow users to browse the information on the page more quickly. Your labels and inputs can fill up the screen without having to adjust the width to fit them on one line.

If they are all on one line, the width of the label and input will be limited.

Turn on label-Position Glitch to see the effect in action.

use<button>

Use to dry button work! Button elements provide frictionless behavior and built-in form submission functionality, while you can easily restyle them. You don’t have to use

or any other element to pretend to be a button.

Make sure your submit button accurately describes what it does. For example, create an account or log in rather than submit or start.

Ensure that the form submission action succeeds

Helps the password manager understand that the form has been submitted. There are two ways to do this:

  1. Navigate to a different page
  2. useHistory.pushState()orHistory.replaceState()To simulate navigation and remove the password form.

When requesting XMLHttpRequest or FETCH, make sure the login success is represented in the return, and handle it by removing the form from the DOM and notifying the user of success.

Consider disabling the login button when the user clicks it. Many users click the button multiple times, even when the page is fast and responsive. This slows down the interaction and increases the burden on the server.

In contrast, don’t disable the submit button while waiting for user input. For example, don’t prohibit the user from submitting a password before it has been entered. Users may forget to fill in the corresponding input and think the page is not working after repeatedly clicking the disabled login button. If you must disable, explain to the user what they forgot when they click the disable button.

⚠️ Warning: The default type of the button in the form is Submit. If you want to add another button (such as a real password), add a ‘type= “button”. Otherwise, clicking or touching it will submit the form.

Don’t force the user to type the same thing twice

Some sites force users to type in their email or password twice. This may reduce the error rate for some users, but it will trouble all users, and it also increases the abandonment rate. Asking for a password twice is unnecessary when a browser automatically populates a mailbox or recommends a strong password. Allowing users to verify their email addresses would be a better step, and make it easier for users to reset their passwords.

Use the attributes of elements well

This is where the magic happens! The browser has many useful built-in features that use Attributes.

Help users start typing faster

Add the Autofocus attribute to the first item of the form. This makes it clear where to start, and means that the user, at least on the desktop, doesn’t have to select an input field to type in.

Autofocus provides clear visual focus on the desktop

Keep passwords private – but allow users to view them when they need to

Password input should add type= “password” to hide the text of the password and to help the browser understand that this is a password input. (Browsers use a variety of ways to understand the role of input boxes and decide whether to provide the ability to save passwords.)

You should add an icon or button that displays the password for the user to check the password they entered — and don’t forget to add a link to forget the password. How to display passwords.

Allow mobile phone users to use the correct keyboard

Use to enable mobile phone users to use the appropriate keyboard, and turn on the built-in basic email address authentication… None of this requires JS!

If you need a phone number instead of an email, will open the phone keypad on the phone. You can also use inputMode when you need to, such as inputmode= “numeric”, which is a good way to enter PIN. Everything you’ve ever wanted to know about InputMode in more detail.

Caution: Type = “number” adds an up/down arrow to the input, so don’t use it for numbers that don’t need to be added, such as IDS or account numbers.

Prevents the keypad from blocking the login button

Unfortunately, the phone’s keyboard can block your forms and even your login button if you’re not careful. In that case, users are likely to give up logging in before they even know what’s going on.

Login button: visible on the left, but not on the right

Where possible, prevent blocking by placing only the mailbox, password entry field, and login button at the top. Put everything else at the bottom. This keyboard does not block the login button

Test your page on a range of machines

You need to test on a range of machines that your target audience is likely to use and adjust accordingly. BrowserStack provides a list of real – and browser tests for open source projectsfree testing for open source projects Login button: Blocked on iPhone 7 and 8, but visible on iPhone 11

Consider having two pages (typed separately)

Some sites (including Amazon and eBay) circumvent this problem by using two separate pages for email and password. This approach also makes the experience easier: users only have to do one thing at a time.

Ideally, this should be done with a

element. Use JavaScript to first show just the mailbox input, then hide it and show the password input. If you must force the user to move to a new page to enter the password, the form on the second page should include a hidden input box with the mailbox value to ensure that the password manager saves the correct value. The password form style that Chromium understands is an example.

Helps users avoid re-entering data

You can help the browser save the data correctly and populate it automatically, so the user doesn’t have to go to the stamp box and password. This is especially important on mobile, especially when entering a mailbox, which often leads to high recklessness

There are two parts to this:

  1. Autocomplete.name.id 和 typeProperty helps the browser understand the role of the input box to store the data that will be used to auto-populate later. Modern browsers generally require a stable input field if you want to enable autofillnameorid, and is located in asubmitButton on the<form>In the.
  2. autocompleteHelp the browser automatically enter data through the store

Use autocomplete= “username” for email input, as username is recognized by password managers in most modern browsers, although you should use type= “email” and use ID = “email” and name= “email”.

For password entry, use the appropriate autocomplete value to help the browser distinguish between new and existing passwords.

Used when the user enters a new passwordAutocomplete = "new password"

  • Use name= “new-password” for the new password in the registration page or change password page. This tells the browser that you want to save a new password

Used when a user enters an existing passwordAutocomplete = "current password"

  • Use the old password on the login page or change password pageAutocomplete = "current password". This tells the browser that you want to use your old password.

Registration Form:

<input name="New password" type="Password"... >
Copy the code

Login form:

<input name="Current password" - type="Password" autocomplete="Current password" -... >
Copy the code

Password manager is supported

Different browsers have different autofill and password recommendation behaviors, but the effect is basically the same. – After Safari 11, show password manager first, then biometric verification (fingerprint or facial recognition) if available

Login through auto complete, no need to enter any text

Desktop Chrome will display email recommendations based on your input, password manager, and then automatically fill in the password.

Caution: browser passwords and auto-fill systems are not simple. Presumably, the algorithms for storing and displaying are not standardized and perform differently on different platforms. For example, Hidde de Vries points out that “Firefox’s password manager complements its heuristics with a recipe system.”

Autofill: There’s a lot of information web developers should know, but don’t know, about how to use Name and Autocomplete. The HTML Spec lists all 59 possible values.

Enable the browser’s ability to recommend robust passwords

Modern browsers use heuristic algorithms to determine when to present a password manager and recommend robust passwords.

Here’s how Safari behaves on the desktop:

(Safari offers robust and unique password features from 12.0 onwards.)

Using the built-in password generator means that neither users nor developers have to worry about what a robust password is. Because browsers can safely save passwords and automatically enter them. Users no longer need to remember and enter passwords.

The downside of this approach is that it is difficult to share passwords across different platforms.

Helps users avoid accidentally forgetting an input

Add the required attribute for the mailbox and password. Modern browsers automatically prompt missing items and change focus to true items. No JavaScript required!

Designed for fingers and thumbs

The default size of input elements and buttons is too small, especially on mobile phones. This may seem obvious, but it’s a common problem with many websites’ login boxes.

Make sure input fields and buttons are large enough

The default size of input fields and buttons is too small for the desktop, let alone the phone.

According to the Android Accessibility Guide, the recommended target size for touch screen components is 7-10 mm. The Apple Interface Guidelines recommend 48×48 pixels, and the W3C recommends at least 44×44 CSS Pixels. From there, add (at least) 15px padding for the input elements and buttons on the phone, and 10px padding for the desktop. Try these sizes for practical use. You should be able to comfortably click on all input elements.

The size of the touchable object does not fit. The Lighthouse Audit helps you automatically discover elements that are too small.

Design for thumb

When searching for Touch Targets, you’ll see a lot of photos using ☝️. But in real life, most people use their thumbs to interact with their phones. The thumb is larger than the index finger, so the operation is less accurate. All the more reason to adjust the touchable area to be large enough.

Make the text big enough

Like the size and padding above, the default font size for input components and buttons is too small, especially on mobile phones.

Default size for desktop and mobile: The size of the text in the input box is too small for many users to read

Different browsers have different methods for resizing text, so listing a common size can be difficult. A quick survey of popular pages shows 13-16 pixels on the desktop, while matching the physical size on mobile is a good bottom line.

That means you should use a bigger size on your phone. 16px is a clear size on the desktop, but on Android it’s hard to read even for people with good vision. You can use Media Queries to set different sizes. 20px is basically a mobile-friendly size, but you should test these out with friends and colleagues who are visually impaired.

Document doesn’t use Legible font Sizes Lighthouse Audit helps you automatically find text that is too small.

Leave enough space between different input fields

Add a Margin large enough between input fields to work as well as touch targets. In other words, leave a margin about a finger wide.

Make sure your input box is clearly visible

The Inputs component’s default border style makes them hard to see. On some platforms (Chrome for Android) they can even be invisible.

As with padding, the solution is to add border: on a white background, a good rule is to use # CCC or a darker color.

Use browser functionality to prompt for invalid input

Browsers have built-in functionality to do basic form validation for typed inputs. The browser will alert you when you submit non-compliant form data and focus on the problematic input.

You can use the invalid CSS selector to highlight invalid data. Use :not(:placeholder-shown) to avoid selecting blank input.

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}
Copy the code

Try different ways to highlight input fields with invalid data.

Use JS when needed

Toggle the display of passwords

You should add an Icon or button that displays the password to allow the user to check what they have typed. Usability suffers when users cannot read the text they enter or leave. There is currently no built-in way to do this, although it is planned. You still need to use JS.

The following code shows how to implement this functionality for real passwords.

HTML:

<section>
  <label for="Password">Password</label>
  <button id="Toggle - password" type="Button" aria-label="The Show password as plain text. Warning: this will display your password on the screen.">Show password</button>< -- -! HERE - ><input id="Password" name="Password" type="Password" autocomplete="Current password" - required>
</section>
Copy the code

Here is the CSS that makes the button look like normal text:

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn’t shown here. */
  font-size: var(- mobile - the font size);font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}
Copy the code

And the JavaScript to display the password:

const passwordInput = documentDocument.getelementbyid (" password ");const togglePasswordButton = documentDocument.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 the passwordas'+' Warning:thisWill display your password on the screen. '); }}Copy the code

This is the final result:

Make password input more accessible

Use aria-descriedby to generalize the rules of a password by giving the ids of the elements that describe the rules. The screen reader reads label, input type, and introduction.

<input type="Password" aria-describedby="Password - constraints"... >
<div id="Password - constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>
Copy the code

When you add the display password function, make sure you also add aria-label to warn that the password will be displayed. Otherwise, the user might accidentally display the password.

<button id="Toggle - password" 
        aria-label="The Show password as plain text. 
                    Warning: this will display your password on the screen.">
  Show password
</button>
Copy the code

Make forms accessible There are more tips to help make forms accessible.

Real-time and pre-submission verification

HTML form elements and Atrributes have built-in functionality for basic validation, but you should also use JS for more robust validation when a user enters data or attempts to submit.

Warning: User-side validation helps users enter data and avoid meaningless server load, but you also need to validate and clean up data on the back end

Step 5 of the codelab login form uses the Constraint Validation API (already widely supported) to add custom rules to leverage the browser’s built-in UI to tweak focus and display hints.

Use JavaScript for More Complex real-time Validation.

Analysis and RUM (Real User Monitoring)

“You can’t improve what you can’t measure” is especially true on registration and login forms. You need to set goals, measure success, and improve your page — and repeat.

Discount Usability testing is very useful when trying new changes, but you still need real world data to fully understand the user experience when using the registration and login forms.

  • PV, bounce rates, and exits.
  • Interaction Analysis: Goal Funnels (When do users give up their registration or login?) And events (What did the user do when interacting with the page?)
  • Page Performance: User-centric Metrics (Is your login or sign-up page slow, and if so, why?) .

You may want to consider doing A/B testing to try out different registration and login methods, as well as staged releases to validate small changes.

General Guidelines:

A well-designed UI and UX can reduce the abandonment rate of login forms

  • Don’t let users figure out how to log in! Put a login link at the top of the page and use the words everyone knows to log in, create an account or sign up.
  • Stay focused! The sign-up page should not be a place to distract users with discounts or features.
  • Reduce login complexity. Collect user data (such as address or credit card information) only when the user can see significant benefits.
  • Make it clear what the user’s benefits are before they log in. What they can gain from logging in. Give the user enough incentive to complete the registration.
  • If possible, allow users to identify themselves only by their mobile phone number rather than email, as some users may not use email.
  • Make it easy for users to reset their passwords and make the forget password link more obvious.
  • Add a link to your service and privacy policy: Make it clear to users how you are protecting their data
  • Add your company logo and make sure the page language, font and style are consistent with other pages. Some forms don’t feel like they belong on the same site as other content, especially if they have different urls.

Continue to learn

  • Create Amazing Forms
  • Best Practices For Mobile Form Design
  • More capable form controls
  • Creating Accessible Forms
  • Streamlining the Sign-in Flow Using Credential Management API
  • Verify phone numbers on the web with the Web OTP API

Photo by Meghan Schiereck on Unsplash .

Welcome to “Byte front end ByteFE”

Resume mailing address: [email protected]