Skip to content

Technique H98:Using HTML 5.2 autocomplete attributes

Applicability

All HTML form fields that map to the HTML 5.2 autofill tokens.

This technique relates to 1.3.5: Identify Input Purpose (Sufficient).

Description

The objective of this technique is to programmatically link a pre-defined and published taxonomic term to the input, so that the inputs can also be machine-interpreted. This way the input will always have a common, referable and identifiable value associated to it, no matter what language is used, or what visible on-screen term is used to label the input. Then it can be further customized or otherwise machine-manipulated to help users.

The technique works by adding the appropriate autocomplete token to each form field on the form to make the identified inputs Programmatically Determinable. This will help people with cognitive disabilities who may not immediately know the purpose of the field because the label used by the author is not familiar to them. When inputs have been programmatically assigned, third party plugins and software can manipulate these form fields to make them more accessible to people with cognitive disabilities. For instance, a plugin could detect an autocomplete token with the text string "tel" and insert a telephone icon. It will further enable third party software to swap out the existing labels for text labels that the user finds more familiar. For instance, it could change "Given Name" to "First Name".

The autocomplete attribute also improves the browser's ability to pre-populate form fields with user-preferred values. When the input has been properly "tagged" with the known token value, the value entered by the user is stored locally on the host machine and associated with the token value for reuse. It helps those with dexterity disabilities who have trouble typing, those who may need more time, and anyone who wishes to reduce effort to fill out a form.

The autocomplete attribute allows the browser to do a pattern match against a list of values locally stored with the browser, and supplies the appropriate corresponding value when the input is programmatically tagged. This is a user setting that can be turned on or off, or modified by the end user. This reduces typing and reliance on memory because it uses stored values to fill in the fields.

It's important to note the Success Criterion Identify Input Purpose and autocomplete attribute only place requirements on input fields collecting information about the user.

For the Success Criterion, it is assumed that the autocomplete attribute is not used on form fields that do not correspond to an autocomplete field described in the HTML autocomplete attribute specification. If the autocomplete field is used to describe a "custom" taxonomy, rather than that described in the specification, this rule may produce incorrect results.

Security considerations

Organizations can be concerned about allowing input fields to be automatically filled-in. There is sometimes confusion about how browsers save information and the security implications.

For the autocomplete attribute:

  • This technique should only be used when asking for data about the user who is filling the form in, not for other people.
  • It only works if you are on the same computer, using the same user-account, and using the same browser. Any multi-login scenario does not save autocomplete data between different accounts. (Users can setup syncing of data across computers, but that is not the default.)
  • Saving information with autocomplete is opt-in by the user, usually at the point of saving data the first time.
  • The form is not auto-submitted, the user can see the data before it is submitted.
  • It is easy to wipe both history and form data in the browser settings.
  • It is easy to engage a privacy mode, such as private browsing.
  • Even without autocomplete set in the webpage, browsers can save data, and some plugins (such as password managers) will aggressively use heuristics to guess what fields are for and fill them in. Using the autocomplete attribute makes those guesses accurate.

The browser history provides far more detail about what people have done, and is just as available as autocomplete data. The solutions/mitigations for browser-history are similar to autocomplete.

Examples

Example 1: A user's credit card information

This is a simple form that collects contact and credit card information from the user.

<form method="post" action="step2">
  <div>
    <label for="fname">First Name</label>
    <input autocomplete="given-name" id="fname" type="text">
  </div>
  <div>
    <label for="lname">Last Name</label>
    <input autocomplete="family-name" id="lname" type="text">
  </div>
  <div>
    <label for="cc-num">Credit card number:</label>
    <input autocomplete="cc-number" id="cc-num" type="text">
  </div>
  <div>
    <label for="exp-date">Expiry Date:</label>
    <input autocomplete="cc-exp" id="exp-date" type="month">
  </div>
  <div>
    <input type="submit" value="Continue">
  </div>
</form>

Tests

Procedure

For each form field that collects information about the user and corresponds to an autocomplete field described in WCAG 2.1 7. Section 7: Input Purposes for User Interface Components, check the following:

  1. The form field has a valid and well-formed autocomplete attribute and value pair.
  2. The purpose of the form field indicated by the label corresponds with the autocomplete token on the input.

Expected Results

  • If #1 and #2 are true, then the test passes and the technique has been successfully implemented.
Back to Top