When it comes to address complete or type-ahead solutions, there are some things that we can control as implementers, and some things we cannot control.
In this article, we will be examining the overlayed box of saved autofill suggestions and its behavior, along with how much we can influence the user experience. We will look at this with and without the browser autofill overlay, as demonstrated in the next two screenshots. The first screenshot is what implementers want or expect, and the second is what they sometimes get, depending on the browser version and platform.
The focus here will be on the browser’s autofill settings, such as the Google Chrome settings in the example below.
With that, we will be observing the behavior that happens using the setting that we can control, the HTML attribute setting, as in the following example.
It is important to note that the settings we provide, when it comes to autocomplete, can be overridden by the end user’s browser settings altogether. How they get overridden is browser-specific. A full listing of which browsers and versions support autocomplete can be found here.
For example, older versions of Microsoft Edge, if you set the browser to do autofill, will still restrict autofill on input fields that have the autocomplete attribute set to ‘off’. On the other hand, in Google Chrome, and for the desktop, the autocomplete set to ‘off’ will be ignored if your browser setting is set to autofill. To make things even harder to keep track of, there are also differences between the desktop experience and the mobile app experience. While the desktop version of Google Chrome partially supports and enforces the autocomplete input tag attribute, the mobile version fully supports it. In fact, most mobile versions of their desktop browser counterparts support the setting completely.
While you don’t have control over various desktop flavors of internet browsers and their settings, knowing that the browsers behave differently with that attribute can help with setting up the experience for your end users.
Trying to control the DOTS Global Address Complete solution on desktop experience with respect to autocomplete can be frustrating, due to the interference of the end user’s browser’s autofill setting being turned on, unless you realize a couple of things:
First, it is not a problem of the solution, and it is not a problem isolated to just one or a handful of autocomplete solutions. The problem is with all autocomplete solutions, since they rely on the settings of the end user’s browser.
Second, what people feel or expect should happen when they are implementing autocomplete, is that as the end user types into their address field, suggested addresses are displayed and the user selects one. And that does happen, but when they finish implementation and start testing they notice that as the user types, an extra box is overlayed on top of the dropdown containing the suggestions. This extra box contains autofill options captured by the browser.
Organizations are not going to require that their end users change their browser settings and turn off autofill just so that the form input fields look pretty as the end user types. However, that is okay. The purpose of address complete is to reduce typing and typos for end users as they type what is usually their own address. So while it may look less then desirable when the extra box is overlayed on top of the address complete suggestions, the extra box will contain the correct address. Also, unless your end users have many saved addresses, the extra box will disappear when the user starts typing unless it matches one of the saved addresses.
If it turns out that the user does click on an address suggested by the browser autofill, it is still really important to use our address validation embedded into the DOTS Global Address Complete solution. After selecting the address and the browser fills in the fields, then activate the lookup by clicking into the field. This will allow the final lookup run through the address validation part of the product, returning the details of the validity of the address.
In some cases, the solution can be more controlled. For example, in a call center environment not turning off autofill on the browser would not be very efficient, because when they type an address the overlay will simply be in the way. The end users in this situation can and should change their browser settings and turn off autofill. The end users at a call center wouldn’t find much utility in having the browser overlay saved addresses on top of the suggestions from address complete, since the addresses would not be relevant.
Other browsers support the autocomplete in other ways such as ignoring the autocomplete attribute set to off in circumstances involving usernames, emails and/or passwords.
Is it really that hard to suppress the extra autofill box? Let’s look at one approach that a little research turned up. If any of your HTML elements contain ID’s or text with words used to identify address components, then the browsers will use that information and force the bowser autofill to pop-up when you enter the respective field. For instance, if you have an input field that has the autocomplete attribute set to ‘off’ and you set the id or the label or div around it to contain the word ‘Address One’ or something similar, the browser will ignore the autocomplete attribute setting of ‘off’ and enforce the browser autofill if the browser setting is on. Here’s an example highlighting the items that have the potential to enforce the browser autofill:
To get around this detection by the browser in some instances you can use non-printable/non-visible characters, such as ‘​’, that will not be displayed to the screen to alter the names of some fields. In other cases, such as classes and id’s, you can just use different names. Next is an example that will not have the browser autofill pop up even with the browser autofill turned on:
In this case, we just needed to alter the div text to have the non-printable/non-visible character and changed the input ID to not have address in it. With those two changes, the browser autofill no longer interferes with the DOTS Global Address Complete suggestions as the end user types.
In conclusion, most individual end-users will have their browser setting for autofill turned on and that is not a problem. You can either live with this – since the address in the autofill is usually going to be the correct address – and still validate it with the underlying validation of Global Address Complete, or you can turn off autofill if you are dealing with a lot of data entry, or you can subvert the efforts of the browser and suppress the autofill with naming fields less identifiably.
