 If users ever need to sign in to 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 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 video is about best practice for simple sign-in forms that use an email address and password. It doesn't explain how to use federated login with identity providers like Google or Facebook or how to integrate with back-end services. You can find out more about those topics from the links at the end of the article that goes with this video. In this video, I'm going to talk about straightforward front-end coding best practice, mostly HTML with a little bit of CSS and some JavaScript. I asked the identity team at Chrome what I should talk about and they said, get the basics of sign-in forms right. So be warned, this is simple stuff. It's not rocket science. Before we start, a quick reality check. Do you actually really need users to sign into your site? People don't like being forced to hand over identity information. 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 known to sign-in form at all. Anyway, with all that out of the way, let's get on with it. 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. As I'll show you, using these elements as intended, enables built-in browser functionality, improves accessibility, and adds meaning to your markup. Your basic HTML might start out something like this. So let's break that down. Now, 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. So first things first. To label an 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. Sign-in, heading one. Email with a hint. You associate a label with an input by giving the labels four 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. You know, was I entering an email address, a phone number or an account ID? I can't remember. There are other potential problems with placeholders and you can see the article that goes with this video if you're unconvinced. 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 causes extra work for all users and can increase abandonment rates. I think 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. Next, 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. Now, this is a real example. I was urgently trying to sign into a site and there was no way of knowing what I was doing wrong. Now that HTML code I showed you before is all valid and correct, but the default browser styling means it looks terrible and it's hard to use, especially on mobile. The default browser size for just about everything to do with forms is too small, especially on mobile. This may seem obvious, but you know, 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. Here you can see the various minimum guidelines for target sizes. On that basis, I reckon 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 not about a finger width and 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. You know, 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, the good general rule is to use a hash 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. If you search for touch target, you'll see lots of pictures of four fingers. However, in the real world, most people, many people use their thumbs to interact with phones. Thumbs are bigger than four fingers 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. Now, let's talk about 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. Okay, we've touched on elements and a bit of CSS. Now I want to talk about attributes. You know, this is where the magic really happens. Browsers have multiple helpful built-in features that use input element attributes. So let's take a look. 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 equals 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. As I'll show you, browsers also use the name and ID attributes to work out the role of form inputs. Use input type equals 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 equals tell enables a telephone keypad on mobile. You can also use the input mode attribute where necessary. Input mode equals numeric is ideal for pin numbers. But watch out. Using type equals 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. And while we're talking about keyboards, unfortunately, if you're not careful, mobile keyboards may cover your form or worse, partially obscure the sign-in button. Users may get confused and 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. So next up, the name and auto-complete attributes. Though 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 auto-complete. So don't make the browser guess. Some browsers, including Firefox, also take note of the ID and type attributes. And when the user later accesses a sign-in form on the same site, the auto-complete attribute enables the browser to auto-fill 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 auto-fill 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 equals 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 wanted to store a new password for the site. Use name equals 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 wanted 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 eagles new password. Modern browsers suggest a strong password if that's included for the password input in a signup 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 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. And I'll say it again, no JavaScript required. So I've talked about the basics of getting HTML and CSS right, but you're also going to need some 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. Here's how Gmail does it. It's really straightforward. You add a listener to your button and in the handler 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 described by 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 backend. The sign-in form codelab goes with this video, uses the constraint validation API, which is widely supported, to add custom validation using built-in browser UI to set focus and display prompts. Okay, one really important extra thing. What you cannot measure, you cannot improve is particularly true for sign-up and sign-in forms. 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 the users abandon your sign-up or sign-in flow and events, what actions do users take when interacting with your forms? And lastly, 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? And finally, some general guidelines to help reduce sign-in form abandonment. Number one, 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 do 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, you know, 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. Make it clear to users from the start how you safeguard their data. And finally, finally, 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. Some forms just, you know, they just feel like they don't belong to the same site as other content, especially if they have a significantly different URL. So there you go. That's the basics of sign-in form best practice. And you can find out more from the web.dev article that goes with this video and the codelab that goes with that. I hope that's given you a few items to add to your next sprint to improve your website's forms. Of course, sign-up and sign-in, you know, it's not the only place that involves a lot of form-filling that could be improved. So stay tuned for Agie, who's gonna talk through some of the new options for payments on the web. Thanks for watching.