 Nobody likes being forced to enter data in forms on websites, especially not on mobile and certainly not when you're out and about and you're busy trying to get 10 things done at once. Autofill by the browser helps users to avoid re-entering data. Autofill can increase data accuracy and make forms more accessible. People like Autofill. Chrome data shows that users trigger Autofill more than 50% of the time when it's offered. And we see fewer forms abandoned when data is autofilled. So getting Autofill to work well is a collaboration between the browser and the web developer. Browsers need to interpret form code to provide easy-to-use interface features on desktop and mobile to enable the user to store Autofill data and then select from those stored values each time they encounter a form. Now, at the same time, web developers need forms to fit their data requirements and that doesn't always work as well as intended. So I'm Sam Dutton, a developer advocate working with the Chrome team and in this session, I'll show you a few ways that Chrome is evolving to make Autofill work better. Now, just going back to basics for a moment. Well, what actually is Autofill in Chrome? Well, Chrome helps users manage their commonly shared personal data to store and a fill, address, payment and login forms. Now, here you can see Chrome Autofill storing an address that's entered in a form and you can manage your Autofill data in Chrome settings and then use data for Autofill in forms on different sites. Now, one thing you might also have seen Chrome offers suggestions for input fields that are not related to address or credit card or login data. Well, in addition to offering Autofill for structured sets of data, such as address and payment details, Chrome helps users avoid having to re-enter data for single form fields that can't be handled by Autofill. When a form has a field with a name attribute that Chrome has encountered before, Chrome can suggest values so you don't need to re-enter data. Now, looking at the Chrome DevTools, you can see from the code that this form field doesn't have attributes that are meaningful to the browser. It has a name attribute of N300 and well, that's it. The field does not correspond to a value in a set of structured data that would make it appropriate for Chrome Autofill, but Chrome can still help the user if Chrome encounters a field with this name in the future. The Chrome DevTools team is building additional new features to help you debug forms and debug Autofill. These features are at an early stage of design and implementation and we need your help to make sure we get them right. And I'll explain later how to access the new features and how to give us your feedback. DevTools can help developers understand how Autofill works and why it sometimes fails. What criteria are used by Autofill to fill a form field, which fields didn't get filled by Autofill? And last, why does a form field not get filled by Autofill? So, first up, we've added functionality to the Chrome DevTools issues tab in the elements panel to help developers debug Autofill glitches. Open the issues tab on a page that includes a form with problems. And as you can see here, this form is a mess. You know, there's a form field without an ID or name attribute, elements with duplicate IDs, a label with a four attribute that doesn't match an element ID and a field with an empty autocomplete attribute. To try out the new functionality, for the moment, you'll need to run Chrome from the command line with the Autofill enabled DevTools issues flag. Now, on Mac, the command looks like this. And just an obvious tip here, you know, whenever you're regularly running Chrome with a flag, you might want to set an alias for that command like this. The DevTools issues tab can also highlight Autofill accessibility problems such as a form field that's missing an ARIA labeled by attribute or label. And we're also working on a dedicated Autofill panel in DevTools. As well as building new Autofill debugging tools for developers, we're continuing to enhance the Autofill experience for end users and to help them avoid re-entering data whenever that's possible. In particular, Chrome has made several improvements to Autofill accessibility. Autofill can help make forms more accessible and easier to use for everyone, especially users with cognitive or motor disabilities, impaired vision or impaired memory. If you get Autofill right, forms can also work much better with assistive technologies. For example, to improve the way Chrome Talkback works with Autofill and the way events are handled by Chrome Autofill, how we announce when form elements are filled on Mac OS and improvements to how we announce the password generation pop up on desktop. Along with accessibility fixes, we're continuing to find ways to make data entry quicker, easier and more accurate and to help users avoid having to re-enter data whenever possible. First up, keyboard accessory. A good Autofill experience isn't just about functionality. You know, you need to get the interface design that's appropriate to the device. On mobile, providing Autofill suggestions in a drop-down menu can make a form hard to use, in particular when the menu gets in the way of the form underneath. We need to allow Autofill without obscuring form UI to make sure users are aware of multiple Autofill suggestions. So we've experimented with using UI chips instead of menu items. And by the way, if you swipe all the way to the right, you can also use this accessory to manually access your Autofill data from any form filled, you know, regardless of how Chrome classified it. Next, payments bottom sheet and touch to log in. Well, in the past, when Chrome offered to fill credit card details, we used the same UI approach as for desktop for the Autofill menu. And, you know, this kind of works, but it's not optimal because, again, the menu covers most of the screen real estate, and it's also hard for users to dismiss the menu. For passwords, we solve this with touch to log in. The first time the user interacts with a field, instead of the keyboard, a more prominent bottom sheet is displayed. For payment form Autofill, Chrome is taking a similar approach. And you can try out the payment bottom sheet functionality by enabling enable Autofill touch to fill for credit cards from Chrome flags in Chrome beta. By the way, on the subject of payments, many merchants rely on iframes hosted by a payment service provider to segregate credit card information from their website to make it easier for the site to reach PCI compliance. Now, this means that each credit card field may be in a separate iframe. Chrome has launched Autofill's support across these iframe boundaries, so you trigger Autofill on the first or second or third field and all the other fields are automatically filled as well. Now, that said, sometimes the credit card holder name is the first field of a credit card form and is hosted in the main frame. So if a user triggers Autofill for their credit card on the main frame, we respect the security origins and don't fill into iframes that are hosted on different security origins. Overall, we recommend having all fields of a credit card form on the same security origin. And going forward, we're trying to build consensus about a mechanism that allows the main frame to explicitly opt into filling into iframes. I want to finish with a few tips to help you code forms so they work really well with Chrome Autofill. And the key idea here is to help your browser, help your users. So first, avoid non-standard autocomplete values, even if they're well-intentioned and make sense for your site's internal data systems. Chrome's Autofill is smart enough to figure out the purpose of a web field even when there's no autocomplete attribute specified, but using a non-standard autocomplete attribute can really cause problems. Using non-standard values for autocomplete means that Chrome Autofill is unlikely to work. Now, you can find a list of standard values on the MDN autocomplete page. And by the way, don't try to use nearly but not quite autocomplete value. Once again, use standard values or nothing. In the example here, the form uses company, but the standard autocomplete value is organization. Likewise, the standard value is family name, not last name. If there is no appropriate values, well, it's better to use no autocomplete attribute rather than an approximation. You should also avoid giving the autocomplete attribute a non-standard value to fit your site's data requirements, such as billing logic. The autocomplete attribute is designed to allow your site code to help the browser. So just to reiterate, it only works with standard values and non-standard values can break Autofill for the user. So use the name or ID attribute instead where you need to. And if necessary, leave out autocomplete. Next, the humble label element. Well, this helps browsers and assistive devices, such as screen readers, to understand the meaning and purpose of form fields in order to provide a better experience for users. And the most important point here is to correctly use the for attribute. The label should have a for attribute that matches the ID of a form field. By the way, the new Chrome DevTools features will warn if you get this wrong. Now, one obvious thing to remember is that if you incorrectly mark up a form, then the user is more likely to store data in Chrome that's incorrect. Of course, we try to prevent this, but simple mistakes can unknowingly lead to a persistently bad user experience. So please double check your form code, ID, name and attribute values. Now here, the form uses last name instead of the standard value, family name and company instead of the standard organization. And by the way, also be careful to wrap logical units in individual form tags. For example, don't mix a login form with a shipping address form. And finally, a reminder that when you help browsers do autofill well, you'll make your forms far more accessible for your users. And you should always check how autofill works with assistive devices for your forms. So let's see how Chrome TalkBack handles autofill on a valid address form on Android. Address form, edit box, name, double tap to edit text, passwords available, showing autofill pop-up, showing English, UK, QWERTY. Sam Dutton, N1C4 hag, enlist showing autofill pop-up, window pop-up window. The form was filled in. Sam Dutton, actions available, use tap with three fingers to view. Now you can learn a lot more about autofill forms and more from our guidance on web.dev. We also have several forms, code labs and these are a great way to help newer members of your dev team to get to grips with the basics of autofill and form best practice. To find out more about the new Chrome DevTools features for debugging autofill, check out our blog post and you can find out there how to provide feedback, how to suggest improvements, new features and to warn us about bugs. So thanks for watching.