Using autocomplete for accessibility and improved user experience

Filling in forms can be a frustrating and tedious task. It's often not helped by the fact that we are regularly asked for the same information from one form to the next.

Thankfully, web browsers have increasingly been helping reduce the repetition. The introduction of autocomplete on form fields has helped us complete forms faster by suggesting form data we've previously entered elsewhere.

Most browsers will enable autocomplete by default. They will use their own judgement to determine what the intended purpose of a form field is; then using a person's input history, suggest values to populate the form with.

As developers, we can use the autocomplete attribute to define the purpose of a field, removing the browser's guesswork. This leads to more accurate suggestions from past form completions.

The autocomplete attribute has been part of the HTML5 specifications since 2012. It is well supported by today's browsers, but developers still seem slow to adopt using it. This is disappointing as not only does it improve the general user experience, it also helps with accessibility.

Identifying a field's purpose

To understand how autocomplete can help with accessibility we can look at the WCAG 2.2 requirements. These define criteria for meeting different levels of accessibility.

At level AA, which should be the minimum we aspire to, we have (1.3.5) Identify Input Purpose which states:

The purpose of each input field collecting information about the user can be programmatically determined when: the input field serves a purpose identified in the Input Purposes for user interface components section; and the content is implemented using technologies with support for identifying the expected meaning for form input data.

We can provide some indication of the purpose of a field using input types like email, tel or password. However, these are broad descriptions. They don't fully describe a field's purpose. Take the example of a password, are we asking for the user's current password or a new one?

To properly indicate purpose we can use, where appropriate, the autocomplete attribute. The HTML specs have a complete list of possible autocomplete values.

As an example, consider a simple form where a user can change their password.

<form method="post" action="/form">
    <div>
        <label for="current_password">Current password</label>
        <input type="password"
            id="current_password"
            name="current_password"
            autocomplete="current-password" />
    </div>
    <div>
        <label for="new_password">New password</label>
        <input type="password"
            id="new_password"
            name="new_password"
            autocomplete="new-password" />
    </div>
    <div>
        <label for="confirm_password">Confirm new password</label>
        <input type="password"
            id="confirm_password"
            name="confirm_password"
            autocomplete="new-password" />
    </div>
</form>

We use type="password" to describe the type of input and autocomplete to identify the field's purpose. Note that for the new password fields we use autocomplete="new-password". 'new-password' is a special autocomplete value in that it instructs a browser not to autofill a field as new input is expected.

If there isn't an appropriate autocomplete value, then we're limited to just using the field's type to imply it's purpose. This is fine, and in many cases will be the situation we find ourselves in. However, where appropriate, we should be setting autocomplete.

Reducing repetition

From a general user-experience perspective, correctly using autocomplete attributes can reduce some of the tedium of filling in forms.

I am sure I am not alone in finding myself having to fill in things like my address on a near weekly basis (if not more). Until I move, this is likely to be the same data time after time.

The HTML specs define several autocomplete value's we can use to identify address fields.

<form method="post" action="/form">
    <div>
        <label for="street_address">Street address</label>
        <input type="text"
            id="street_address"
            name="street_address"
            autocomplete="street-address" />
    </div>
    <div>
        <label for="city">Town / City</label>
        <input type="text"
            id="city"
            name="city"
            autocomplete="address-level1" />
    </div>
    <div>
        <label for="postcode">Postcode</label>
        <input type="text"
            id="postcode"
            name="postcode"
            autocomplete="postal-code" />
    </div>
</form>

By setting the autocomplete attribute for these fields, we can avoid relying on the browser's judgement over a field's intended purpose. While browser's do their best to figure out what to autofill, they can often get it wrong; this can lead to further frustration as a user will need to go through fixing the values the browser has incorrectly entered (if they even notice the error).

Hopefully, the benefits of specifying the autocomplete attribute should be clear to you. Utilising the browser's ability to autofill from past form data can also help towards the WCAG's (3.3.7) Redundant Entry requirement, which states:

Information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select.

We can usually meet this requirement by populating fields from an application's backend. For example, in a checkout process we may retrieve a customer's delivery address from past orders in the database. However, using autocomplete provides a nice fallback.

Summary

Using autocomplete attributes is required for accessibility. It ensures we define the purpose of form fields and remove the repetition of commonly requested data. This also means we can simplify form completion for our users, regardless of their accessibility needs. This will improve the user-experience and increase the probability of successful form submissions.

If you're not already using autocomplete attributes, I'd recommend checking out the list of possible autocomplete values defined in the HTML specs. As a more readable alternative (the official documentation can be a little academic), MDN's autocomplete documentation provides a reliable resource for the same information.