Can the purpose of an input field be inferred to facilitate the automatic filling of fields with the user's data?

A user with tremors or motor disorders fills out an order form. Entering their address, phone number, bank details: each field is genuine physical effort. If their browser already knows this information and can insert it automatically, why prevent them? The autocomplete attribute is the signal that makes this possible.

This criterion applies to all fields that collect personal user data: name, surname, address, phone, email, credit card number, date of birth. For each relevant field, three conditions must be met: the autocomplete attribute is present, its value belongs to the official HTML specification list, and this value is consistent with the type of information requested. An autocomplete="tel" on an email address field is non-compliance — the value exists in the list, but it misleads the browser.

The official list contains about forty values defined in the HTML5 specification: given-name, family-name, email, tel, street-address, postal-code, cc-number, cc-exp, bday, among others. For forms with distinct sections (billing, delivery), the billing and shipping prefixes allow differentiating homologous fields: autocomplete="billing postal-code" versus autocomplete="shipping postal-code".

A single attribute in the right place, a real difference for millions of users.

Un test to ensure that autofill is available

Valid and relevant autocomplete attribute on personal fields

  1. Identify all form fields linked to personal data: name, surname, email, phone, address, postal code, card number, date of birth, etc.
  2. For each of these fields (<input>, <select>, <textarea>), check the following three conditions: a. The autocomplete attribute is present on the element. b. The autocomplete value appears in the official HTML list (https://www.w3.org/TR/html52/sec-forms.html#autofill-processing-model) — a made-up value like autocomplete="firstname" is non-compliant. c. The value is consistent with what the field actually expects (e.g., autocomplete="email" for an email field, not autocomplete="tel").
  3. The test is validated if each personal field identified meets these three conditions. A single field without valid and relevant autocomplete is enough to invalidate the test.

Examples

❌ Non-compliant : Registration form without autocomplete attribute

<form>
  <label for="prenom">First name</label>
  <input type="text" id="prenom" name="prenom">
 
  <label for="nom">Last name</label>
  <input type="text" id="nom" name="nom">
 
  <label for="email">Email address</label>
  <input type="email" id="email" name="email">
 
  <label for="tel">Phone</label>
  <input type="tel" id="tel" name="tel">
</form>

No autocomplete attribute is declared. The browser may try to guess the purpose of the fields based on the name or label, but this heuristic behavior varies across browsers and is not guaranteed. For a user filling out this form for the tenth time, or who has motor difficulties, reliable autofill is impossible.

✅ Compliant : Registration form with autocomplete correctly filled in

<form>
  <label for="prenom">First name</label>
  <input type="text" id="prenom" name="prenom" autocomplete="given-name">
 
  <label for="nom">Last name</label>
  <input type="text" id="nom" name="nom" autocomplete="family-name">
 
  <label for="email">Email address</label>
  <input type="email" id="email" name="email" autocomplete="email">
 
  <label for="tel">Phone</label>
  <input type="tel" id="tel" name="tel" autocomplete="tel">
</form>

Each field explicitly declares its purpose. The browser — and password managers or autofill services — can reliably pre-fill these fields. The user no longer has to retype information they have already provided elsewhere. Note that given-name and family-name are the correct values, not firstname or lastname which do not exist in the specification.

✅ Compliant : Payment form with billing and shipping prefixes

<fieldset>
  <legend>Billing address</legend>
  <label for="billing-street">Street</label>
  <input type="text" id="billing-street" name="billing-street" autocomplete="billing street-address">
  <label for="billing-zip">Postal code</label>
  <input type="text" id="billing-zip" name="billing-zip" autocomplete="billing postal-code">
</fieldset>
 
<fieldset>
  <legend>Delivery address</legend>
  <label for="shipping-street">Street</label>
  <input type="text" id="shipping-street" name="shipping-street" autocomplete="shipping street-address">
  <label for="shipping-zip">Postal code</label>
  <input type="text" id="shipping-zip" name="shipping-zip" autocomplete="shipping postal-code">
</fieldset>

The billing and shipping prefixes distinguish homologous fields in the same form. Without them, a browser would not know which address to insert into which field. Here, the user's billing and delivery data arrives in the right place without ambiguity.

Tips and pitfalls

⚠️ autocomplete="off" disables the criterion and penalizes your users

Some teams add autocomplete="off" for supposed security reasons — to prevent sensitive data from being remembered in the browser. Double mistake: modern browsers often ignore this directive on login fields, and for users with motor limitations, you remove essential assistance. On a personal data field, autocomplete="off" makes criterion 11.13 non-compliant.

⚠️ Made-up value or value absent from the official list

autocomplete="firstname" or autocomplete="phone-number" are non-compliant values: they do not exist in the HTML specification. The correct values are respectively given-name and tel. This is the most frequent error in audits. Always consult https://www.w3.org/TR/html52/sec-forms.html#autofill-processing-model before using a value you have deduced by intuition.

💡 The HTML type and autocomplete have distinct roles

<input type="email"> helps mobile browsers display the appropriate keyboard, but is not enough to guarantee reliable autofill in the sense of RGAA. You must explicitly add autocomplete="email". The two attributes complement each other: type defines the input format, autocomplete defines the semantic purpose of the field.

⚠️ The <select> elements are also concerned

The autocomplete attribute applies not only to <input>. A <select> for country or region can receive autocomplete="country" or autocomplete="address-level1". The oversight of dropdown lists is common in audits — verify all form controls linked to personal data, not just text fields.

⚠️ Fields with no equivalent in the official list

If your form asks for information that has no match in the official list (customer reference number, internal company code), criterion 11.13 does not apply to that field. The obligation concerns only personal user data in the sense of the HTML specification. When in doubt, the absence of autocomplete is better than an incorrect value.

Frequently asked questions

How does the autocomplete attribute apply to password fields in RGAA?

Yes, with specific values. An existing password field (login) takes autocomplete="current-password". A new password field (account creation, password change) takes autocomplete="new-password". This distinction is important: new-password signals to password managers that they should offer to generate a strong password, not pre-fill the current password.

How to efficiently audit RGAA criterion 11.13 on autofill?

Open DevTools (F12), inspect each field linked to personal data and verify the presence and value of the autocomplete attribute. To move faster on a page, search the source code (Ctrl+U) for the autocomplete string and list all values found. Cross-reference them with the official list. Then test in practice: fill out the form once, come back to it — do the fields offer coherent suggestions?

When is the autocomplete attribute necessary on a search field in RGAA?

No. Criterion 11.13 targets only fields that collect personal user data. A content search field (search for an article, a product) is not in the scope. The value autocomplete="search" exists in the specification, but its use on a search bar is not a requirement of this criterion.

How to choose the correct autocomplete value based on the visible field label in RGAA?

It must be consistent with the purpose of the field, not necessarily with its exact label. A field labeled "Your email" takes autocomplete="email". A field labeled "Mobile number" takes autocomplete="tel". It is what the field expects as information that determines the value, not the wording of the label. Criterion 11.13 is invalidated if the value is technically valid but semantically inconsistent.

References

RGAA 4.1.2: Criterion 11.13
WCAG 2.1:1.3.5 (AA)H981.3.5 (AA)