Autocomplete valid

  • Rule Typeatomic
  • Rule ID: 73f2c2
  • Last modified: Aug 21, 2019
  • Accessibility Requirements Mapping
    • 1.3.5 Identify Input Purpose (Level: AA)
      • Learn More about 1.3.5 (Identify Input Purpose)
      • Required for conformance to WCAG 2.1 and above on level AA and above
      • Outcome mapping:
        • Any failed outcomes: not satisfied
        • All passed outcomes: further testing is needed
        • An inapplicable outcome: further testing is needed
  • Input Aspects


This rule checks that the HTML autocomplete attribute has a correct value.


The rule applies to any HTML input, select and textarea element with an autocomplete attribute that is not empty (""), except if one of the following is true:

Expectation 1

The autocomplete attribute is a single term, or a space separated list of terms.

Expectation 2

The autocomplete term(s) follow the HTML 5.2 specification, which requires that it/they match the following in the correct order:

  1. Has a value that starts with "section-" (optional)
  2. Has either "shipping" or "billing" (optional)
  3. Has either "home", "work", "mobile", "fax" or "pager" (optional, only for "email", "impp", "tel" or "tel-*")
  4. Has a correct autocomplete field (required)

Note: Autocomplete terms are case insensitive. When multiple terms are used, they must be used in the correct order.

Expectation 3

The correct autocomplete field is an appropriate field for the form control.


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

Accessibility Support

While autocomplete in a promising technique for supporting personalisation in HTML, support for this is fairly limited.


The intent of this rule is to ensure that the autocomplete attribute can be used to suport personalization. Many users may find it easier to fill out forms if those can be styled or layed out in a way that is familiar to them. Assistive technologies can do this when a form control is marked up in such a way that its purpose can be understood. For instance, assistive technologies could add familiar icons and colors to different fields, making it easier for the user to understand what the form does.

Test Cases


Passed Example 1

Single autocomplete term.

<input autocomplete="username" />

Passed Example 2

Single autocomplete term for select.

<select autocomplete="bday-month">

Passed Example 3

Autocomplete term, only valid for textarea.

<textarea autocomplete="Street-Address"></textarea>

Passed Example 4

Two autocomplete terms.

<input autocomplete="Work EMail" />

Passed Example 5

Autocomplete using section-*

<input autocomplete="section-partner email" />

Passed Example 6

Triple autocomplete terms.

<input type="text" autocomplete="section-primary billing address-line1" />

Passed Example 7

Full length autocomplete terms.

<input autocomplete="section-primary shipping work email" />

Passed Example 8

The input element does not have a semantic role that is a widget role, but still participates in sequential focus navigation, and has a single autocomplete term.

<input role="none" autocomplete="username" />

Passed Example 9

The input element does not participates in sequential focus navigation, but still has a semantic role that is a widget role, and has a single autocomplete term.

<input tabindex="-1" autocomplete="username" />

Passed Example 10

The input element does not have a semantic role that is a widget role, but still participates in sequential focus navigation since the tabindex attribute value is not a valid integer, and has a single autocomplete term.

<input role="none" tabindex="-1.5" autocomplete="username" />


Failed Example 1

Unknown autocomplete term.

<input autocomplete="badterm" />

Failed Example 2

Term work not allowed before photo.

<input autocomplete="work photo" />

Failed Example 3

Invalid order of terms.

<input autocomplete="work shipping email" />

Failed Example 4

Comma separated rather than space separated list.

<input autocomplete="work,email" />

Failed Example 5

Autocomplete is inappropriate for the type of field.

<input type="number" autocomplete="email" />

Failed Example 6

Autocomplete is not empty, but does not have any terms specified.

<input autocomplete=" " />


Inapplicable Example 1

Inapplicable element.

<button autocomplete="username"></button>

Inapplicable Example 2

Autocomplete attribute is empty ("").

<input autocomplete="" />

Inapplicable Example 3

The element is hidden through display:none.

<input autocomplete="username" style="display:none" />

Inapplicable Example 4

The element is positioned off screen and hidden to assistive technologies

<input autocomplete="username" aria-hidden="true" style="position:absolute; top:-9999em" />

Inapplicable Example 5

The input element has a type attribute that is in the button state.

<input type="button" autocomplete="username" />

Inapplicable Example 6

The input element has a type attribute that is in the hidden state.

<input type="hidden" autocomplete="username" />

Inapplicable Example 7

The input element has an HTML disabled attribute.

<input autocomplete="username" disabled />

Inapplicable Example 8

The input element has an aria-disabled attribute with value true.

<input autocomplete="username" aria-disabled="true" />

Inapplicable Example 9

Non-widget element that does not participate in sequential focus navigation.

<input type="button" role="none" tabindex="-1" autocomplete="username" />

Inapplicable Example 10

Non-widget element that does not participate in sequential focus navigation.

<input type="button" role="none" tabindex="-2" autocomplete="username" />


Included in the accessibility tree

key: included-in-the-accessibility-tree

Elements included in the accessibility tree of platform specific accessibility APIs. Elements in the accessibility tree are exposed to assistive technologies, allowing users to interact with the elements in a way that meet the requirements of the individual user.

The general rules for when elements are included in the accessibility tree are defined in the core accessibility API mappings. For native markup languages, such as HTML and SVG, additional rules for when elements are included in the accessibility tree can be found in the HTML accessibility API mappings (work in progress) and the SVG accessibility API mappings (work in progress).

Note: Users of assistive technologies might still be able to interact with elements that are not included in the accessibility tree. An example of this is a focusable element with an aria-hidden attribute with a value of true. Such an element could still be interacted with using sequential keyboard navigation regardless of the assistive technologies used, even though the element would not be included in the accessibility tree.


key: outcome

A conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target. An outcome can be one of the three following types:

  • Inapplicable: No part of the test subject matches the applicability
  • Passed: A test target meets all expectations
  • Failed: A test target does not meet all expectations

Note: A rule has one passed or failed outcome for every test target. When there are no test targets the rule has one inapplicable outcome. This means that each test subject will have one or more outcomes.

Note: Implementers using the EARL10-Schema can express the outcome with the outcome property. In addition to passed, failed and inapplicable, EARL 1.0 also defined an incomplete outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the incomplete outcome.

Semantic Role

key: semantic-role

A semantic role is a semantic association that indicates an object's type. This allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

The semantic role of an element is its explicit semantic role if it has any, otherwise, the implicit semantic role is used.


key: visible

Content perceivable through sight.

Content is considered visible if making it fully transparent would result in a difference in the pixels rendered for any part of the document that is currently within the viewport or can be brought into the viewport via scrolling.

Content is defined in WCAG.


Aug 21, 2019test: add tests to verify h4 headings (#810)
Aug 21, 2019fix: update links to WCAG21 resources (#776)
Aug 21, 2019Editorial changes (#725)
Jul 26, 2019Editorial changes (#702)
Jul 22, 2019Replace useless visible-on-the-page with visible (#694)
Jul 19, 2019chore: run prettier (#688)
Jul 2, 2019chore: Correct various typos (#640)
May 18, 2019chore: Validating rules frontmatter on CI (#551)
May 15, 2019Glossary and Rule update: Replacing "non-empty" definition (#430)
May 9, 2019Chore: Adapt site to ACT Rules CR format (#547)
May 7, 2019Template update - Autocomplete valid (#502)
Apr 29, 2019chore: rename files and update associations (#489)
Apr 16, 2019chore: add unique id to all rules (#478)
Apr 15, 2019chore: WCAG ACT RULES CG Website Update (#437)
Nov 19, 2018Remove "focusable" and "is visible" from Applicability in several rules due to consistency concerns (#310)
Oct 12, 2018"Included in accessibility tree" instead of "exposed to assistive technologies" (#269)
Oct 9, 2018Fix: testcase generation (#296)
Sep 19, 2018fix: test cases for rules
Sep 18, 2018fix: testcase(s) and adding expected to testcase output
Aug 30, 2018Chore: Update test cases format and descriptions (#230)
Aug 6, 2018Rule: SC1-3-5-autocomplete-valid (#170)

Useful Links


Tool NameCreated ByReport
AlfaSiteimproveView Report