Last updated:

Created by:

Success Criterion:

Description

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

Accessibility Requirements

This conformance rule relates to:

Test Procedure

Applicability

The rule applies to any HTML input, select and textarea element with a non-empty autocomplete attribute, 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.

Exepctation 3

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

Assumptions

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.

Background

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

Passed example 1

Single autocomplete term.

Code Snippet:
 <input autocomplete="username" />
 
Example Output: Open in a new tab/ window

Passed example 2

Single autocomplete term for select.

Code Snippet:
 <select autocomplete="bday-month">
  <option>January</option>
  <option>...</option>
</select>
 
Example Output: Open in a new tab/ window

Passed example 3

Autocomplete term, only valid for textarea.

Code Snippet:
 <textarea autocomplete="Street-Address"></textarea>
 
Example Output: Open in a new tab/ window

Passed example 4

Two autocomplete terms.

Code Snippet:
 <input autocomplete="Work EMail" />
 
Example Output: Open in a new tab/ window

Passed example 5

Autocomplete using section-*

Code Snippet:
 <input autocomplete="section-partner email" />
 
Example Output: Open in a new tab/ window

Passed example 6

Triple autocomplete terms.

Code Snippet:
 <input type="text" autocomplete="section-primary billing address-line1" />
 
Example Output: Open in a new tab/ window

Passed example 7

Full length autocomplete terms.

Code Snippet:
 <input autocomplete="section-primary shipping work email" />
 
Example Output: Open in a new tab/ window

Failed

Failed example 1

Unknown autocomplete term.

Code Snippet:
 
<input autocomplete="badterm" />
 
Example Output: Open in a new tab/ window

Failed example 2

term work not allowed before photo.

Code Snippet:
 <input autocomplete="work photo" />
 
Example Output: Open in a new tab/ window

Failed example 3

Invalid order of terms.

Code Snippet:
 <input autocomplete="work shipping email" />
 
Example Output: Open in a new tab/ window

Failed example 4

Comma seperated rather than space separated list.

Code Snippet:
 <input autocomplete="work,email" />
 
Example Output: Open in a new tab/ window

Failed example 5

Autocomplete is inappropriate for the type of field.

Code Snippet:
 <input type="number" autocomplete="email" />
 
Example Output: Open in a new tab/ window

Inapplicable

Inapplicable example 1

Incorrect element.

Code Snippet:
 <button autocomplete="username"></button>
 
Example Output: Open in a new tab/ window

Inapplicable example 2

Empty attribute.

Code Snippet:
 <input autocomplete="">
 
Example Output: Open in a new tab/ window

Inapplicable example 3

Hidden through display:none.

Code Snippet:
 <input autocomplete="username" style="display:none">
 
Example Output: Open in a new tab/ window

Inapplicable example 4

Off screen and hidden to assistive technologies

Code Snippet:
 <input autocomplete="username" aria-hidden="true" style="position:absolute; top:-9999em">
 
Example Output: Open in a new tab/ window

Inapplicable example 5

type input button.

Code Snippet:
 <input type="button" autocomplete="username">
 
Example Output: Open in a new tab/ window

Inapplicable example 6

type hidden.

Code Snippet:
 <input type="hidden" autocomplete="username">
 
Example Output: Open in a new tab/ window

Inapplicable example 7

Native disabled.

Code Snippet:
 <input autocomplete="username" disabled>
 
Example Output: Open in a new tab/ window

Inapplicable example 8

Using aria-disabled.

Code Snippet:
 <input autocomplete="username" aria-disabled="true">
 
Example Output: Open in a new tab/ window

Inapplicable example 9

Non-widget element.

Code Snippet:
 <input type="button" role="none" tabindex="-1" autocomplete="username">
 
Example Output: Open in a new tab/ window

Glossary

Non-empty text string

A string of characters (text) is considered “non-empty” if it contains 1 or more characters that are contained within any of the following unicode categories:

  • Ll: Letter, Lowercase
  • Lu: Letter, Uppercase
  • Lt: Letter, Titlecase
  • Lo: Letter, Other
  • Lm: Letter, Modifier
  • Nd: Number, Decimal Digit

For more details on unicode categories, check out www.fileformat.info/info/unicode/category/

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 and the SVG accessibility API mappings.

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.

Visible on the Page

Elements should be visible on the page, and also meet the requirements for color contrast and visibility when focused. For more details, check out:

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.

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.

Roles can be implicit through the element type or explicit through the role attribute.

The role attribute takes a list of tokens. The semantic role is the first valid role in this list. If none of the tokens are valid, the implicit role will be used instead.

Non-abstract roles defined in the following specifications are considered valid:

Other roles may be added as they become available. Not all roles will be supported in all assistive technologies. Testers are encouraged to adjust which roles are allowed according to the accessibility support base line. For the purposes of executing test cases in all rules, it should be assumed that all roles are supported by assistive technologies so that none of the roles fail due to lack of accessibility support.

Note: For HTML elements the implicit roles are documented in ARIA in HTML.

Correct autocomplete field

Any field name listed in the autocomplete fields table from the HTML 5.2 specification: https://www.w3.org/TR/html52/sec-forms.html#autofill-field

Appropriate field for the form control

The field name listed in the autocomplete fields table from the HTML 5.2 specification is used in the autocomplete attribute of an element: https://www.w3.org/TR/html52/sec-forms.html#inappropriate-for-the-control

Test Aspects

Test aspects are defined as part of the ACT Rules format 1.0.
  • DOM Tree

  • CSS Styling

Contribute






GitHub

Contributing is open to anyone. We welcome any new issues or pull requests for changes. Auto WCAG Rules has conference calls every 4 weeks. If you are interested in becoming an active contributor or reviewer, we ask that you join the Auto WCAG Rules community group through the W3C Website. This requires setting up a W3C account, may require approval by the organization you work for if they are a W3C member.

Learn more about contributing to Auto WCAG Rules Join the Auto WCAG Rules community group now!