Understanding WCAG SC 1.3.5: Orientation (AA)

Section 1: The Mandate for Programmatic Input Purpose Identification

1.1 WCAG 2.1 Context and Cognitive Accessibility

The introduction of Success Criterion (SC) 1.3.5 in WCAG 2.1 significantly advanced the requirements under Principle 1: Perceivable, specifically within Guideline 1.3: Adaptable. This criterion mandates the provision of specific, machine-readable semantics regarding the type and purpose of user input fields. This requirement directly addresses challenges faced by individuals with cognitive disabilities, memory impairments, or difficulties with executive function by shifting the burden of memory and complex data entry from the user to the user agent. By programmatically identifying the purpose of common input fields, the standard enables adaptive user agents and assistive technologies (AT) to automate form-filling processes, reducing cognitive load and increasing predictability across different web experiences.

1.2 Success Criterion 1.3.5 Formal Definition and Intent

WCAG SC 1.3.5 (Level AA) requires that the purpose of each input field collecting information about the user can be programmatically determined under two specific conditions:

1. The input field serves a purpose explicitly identified in the official W3C Input Purposes for User Interface Components section.
2. The content is implemented using technologies with support for identifying the expected meaning for form input data, typically utilizing the HTML autocomplete attribute.

The central intent of this success criterion is to ensure that the semantic meaning of a form input is available to all user agents, allowing the data purpose to be extracted and presented to users using various modalities. This programmatic declaration of data expectation is crucial for making forms manageable, especially for users who require enhanced support for disambiguation or automation. The definitive technique cited for compliance in web content is H98: Using HTML autocomplete attributes.

1.3 Scope of Application: Defining User-Specific Data and Applicable Input Types

The scope of SC 1.3.5 is deliberately narrow and specific. It is constrained to input fields that accept text-based data and, critically, only applies to fields requesting information about the primary end user themselves.

Applicable Elements and Data

The criterion applies to form controls that accept text input, including standard HTML elements such as <input type="text">, <input type="email">, <input type="tel">, <textarea>, and <select> elements, which are generically referred to as "input" within the success criterion.

Excluded Elements and Data

Inputs that do not collect information about the user are specifically excluded from this requirement. For instance, fields asking for details about a third party, such as an emergency contact's name or a relative’s address, are outside the scope of 1.3.5. Furthermore, non-textual input types, such as checkboxes, radio buttons, file uploads, buttons, images, and submission controls, are also excluded.

Compliance relies on the assignment of the autocomplete attribute, which provides a semantic layer that is distinct from the intrinsic HTML input type. For example, an <input type="email"> element inherently defines the format of the input data as an email address. However, it does not define the purpose—whether it is a primary email, a shipping contact email, or a work email. The criterion mandates adding the specific autocomplete token (email, shipping email, or work email) to define this required semantic meaning, ensuring programmatic determination for the user agent. Therefore, relying on the type attribute alone is insufficient; the specific autocomplete token is mandatory for fulfilling the Level AA requirement.

Section 2: Transformative Benefits for Users and Technology

The implementation of SC 1.3.5 yields significant functional benefits across diverse user groups, extending well beyond general usability improvements. These benefits stem from the standardization and automation enabled by the programmatic input purpose identification.

2.1 Mitigating Cognitive Load, Memory Impairment, and Executive Function Challenges

For individuals with language-related disabilities, impaired memory, or conditions that affect executive function and decision-making, the necessity of remembering, typing, and validating complex personal information during form submission can be highly burdensome.

By leveraging the autocomplete attribute, browsers can reliably auto-fill personal data, such as addresses, names, and phone numbers, eliminating the need for the user to recall or manually enter this information. This automated data entry significantly reduces cognitive friction and fatigue. Although visually clear labels are beneficial, the programmatic identification provides an unambiguous and consistent definition of the field's purpose, which AT can render in a predictable manner. The success of this criterion is founded on forcing standardization; if every website were allowed to use unique labels ("Family Name," "Last Name," "Surname"), AT would struggle with complex natural language processing to guess the intent. By enforcing the use of a fixed, predefined vocabulary (the HTML tokens), cross-site functionality and reliable cognitive support are ensured.

2.2 Enhancing Usability for Users with Motor Impairments

Users with motor disabilities—including those stemming from cerebral palsy, stroke, or head injury—often face substantial challenges when performing fine motor control actions required for typing and navigating forms.

The implementation of autofill functionality dramatically reduces the required number of manual inputs, keystrokes, and overall form interaction time. This efficiency gain is critical for users who experience physical difficulties in filling out forms. Furthermore, fewer manual inputs inherently translate to a lower likelihood of input errors, reducing the frustrating and complex recovery process often required when forms are submitted incorrectly.

2.3 Enabling Adaptive Modalities and Assistive Technologies

The technical fulfillment of SC 1.3.5 establishes a standardized, machine-readable metadata layer that is independent of the field's visual presentation. This metadata is crucial for advanced assistive technologies.

Assistive technologies, including browser plugins, can use the determined purpose (e.g., given-name or telephone number) to offer customized presentation formats. For users who prefer communication through images or symbols due to language or learning disabilities, AT can insert user-preferred icons or symbols next to the field to visually communicate the input purpose. This process, which draws on a set of familiar symbols, enables the user to quickly identify the function of the field without relying on the author-provided text label.

Moreover, compliance is essential for the seamless operation of credential and data managers. Correctly marking fields with tokens like username, current-password, new-password, or cc-number ensures that browser-based password managers and third-party tools can accurately identify the field type and securely populate the correct stored information.

Section 3: Technical Foundation: The HTML autocomplete Attribute

3.1 H98: The Sufficient Technique for SC 1.3.5

The designated sufficient technique for achieving compliance with SC 1.3.5 in HTML is H98, which involves leveraging the autocomplete attribute. This technique relies entirely on the fixed list of tokens standardized by the WHATWG HTML Living Standard (version 5.2 Autofill). This linkage means that technical compliance is inextricably tied to strict adherence to the latest HTML specification for autofill detail tokens.

3.2 Linkage to the HTML Living Standard and Autofill Detail Tokens

To satisfy the criterion, the autocomplete attribute must use an ordered set of space-separated tokens—known as autofill detail tokens—rather than merely the single keywords "on" or "off". This structured token set allows user agents to precisely identify the context and type of information requested.

3.3 Syntax Rules: autocomplete as an Ordered Set of Space-Separated Tokens

A fundamental requirement for compliance, and a technical mechanism for ensuring reliability, is the strict ordering of these tokens. The syntax must adhere to a precise hierarchy defined by the WHATWG standard. This ordered structure is necessary to provide the contextual layering needed to uniquely define complex fields, especially when multiple identical data types (like multiple street addresses) appear within a single form.

The necessity for strict token ordering addresses the potential for namespace collisions in complex forms. If a form contains several fields requesting a generic piece of data, such as a postal-code, the user agent needs context to know which saved postal code belongs to which form field. The token structure resolves this ambiguity by building the identity hierarchically, starting with the broadest context and moving to the specific field name. Failure to maintain the specified order results in an accessibility failure.

Section 4: Deep Dive into the Autofill Token Taxonomy

The autocomplete attribute’s ordered token set consists of up to six distinct token types. The Core Field Name Token (Position 4) is the mandatory semantic definition that directly satisfies the "Identify Input Purpose" requirement, while the preceding optional tokens provide crucial context for disambiguation.

Table 1: The Ordered Hierarchy of Autofill Detail Tokens

4.2 Core Field Names: Semantic Mapping of Personal Data

The Core Field Name tokens are standardized keywords essential for compliance. These tokens are categorized by the nature of the information they represent:

4.2.1 Identity and Contact Tokens

These tokens define elements of personal identification and digital contact points. Examples include given-name, family-name, name (for full name), nickname, organization-title, and organization. Crucially, when defining contact information, the tokens must often be combined with a Recipient Type token (Position 3). For instance, an email field must use work email or home email to refine the purpose beyond a simple email type.

4.2.2 Geographic Address Tokens

These define the components of a physical address structure, relying on a predefined system of address levels to support global address formats. Examples include street-address, address-line1, address-line2, address-level2 (commonly city or province), country, and postal-code. It is standard practice to adhere strictly to these predefined address levels rather than attempting to create non-standard, locale-specific address schemas.

4.2.3 Financial and Payment Tokens

These are used for identifying credit card and related payment details, enabling secure autofill integration with browser and third-party payment managers. Key tokens include cc-name (name on the card), cc-number, cc-exp-month, cc-exp-year, and cc-csc (card security code). Best practice for compliance and user experience suggests consolidating numbers like credit card numbers and telephone numbers into a single input field to maximize the reliability of the autofill prompt.

4.2.4 Authentication Tokens

Critical for login and registration processes, these tokens enable robust integration with password managers. Examples include username, new-password, current-password, and one-time-code. These tokens ensure that password managers can differentiate clearly between fields intended for creating a new credential versus logging into an existing one.

The function of the optional section-* token, which provides developer-controlled segmentation, is purely technical; it is a mechanism for defining an opaque namespace for instance-level form disambiguation. The specification explicitly states that user agents must not attempt to derive any inherent semantic meaning from the value following section- (e.g., if a developer uses section-child, the browser should not assume the address belongs to the user’s child). The semantic meaning of the field remains communicated by the combination of the shipping/billing token and the Core Field Name token.

Section 5: Advanced Implementation: Segmenting Complex Forms

In complex web applications, such as e-commerce platforms, developers frequently need to present multiple sets of related user information within a single form context. Proper programmatic determination requires employing the token hierarchy to segment these groups reliably.

5.1 The Grouping Identifiers: shipping vs. billing

When a form requests contact or address information for transactional purposes, the Context/Address Type tokens (shipping or billing) must be utilized. These tokens occupy the 2nd position in the ordered token list and serve to differentiate the data sets.

For example, to differentiate between the addresses used for delivery and for payment processing:

• Shipping Address Line 1: <input autocomplete="shipping address-line-1"...>
• Billing Address Line 1: <input autocomplete="billing address-line-1"...>

This mechanism ensures that the user agent suggests the appropriate saved data for the correct context, thereby preventing the mixing of delivery and financial addresses.

5.2 Utilizing the Opaque section-* Prefix for Unique Grouping

When a form requires two or more instances of the same type of address or contact information (e.g., two distinct shipping addresses for different gift recipients, or two billing addresses for different payment methods), the shipping or billing token alone becomes insufficient for unique identification. In such cases, the optional section-* token (Position 1) must be used to create a unique anchor for each group.

The prefix section- must be followed by an alphanumeric string that serves as a unique identifier for that group (e.g., section-group-a or section-payment-method-visa). The user agent treats this entire string as a unique namespace, ensuring that autofill data collected for one section remains distinct from data collected in another section, even if the Core Field Name tokens are identical.

5.3 Case Study: Implementation of Separate Shipping and Billing Addresses

To successfully manage data segmentation, developers must understand how to combine the context and section tokens:

• Scenario 1: Simple Differentiation
  • Shipping Postal Code: <input autocomplete="shipping postal-code">
  • Billing Postal Code: <input autocomplete="billing postal-code">
• Scenario 2: Differentiating Multiple Shipping Instances
  Consider a form requesting details for two separate shipping recipients (Gift Red and Gift Blue) using the same core fields. The section-* token must be employed to create unique token lists:
  • Gift Red Shipping Address: <textarea autocomplete="section-red shipping street-address"></textarea>
  • Gift Blue Shipping Address: <textarea autocomplete="section-blue shipping street-address"></textarea>

This structured tokenization provides the user agent with sufficient specificity to maintain two distinct contexts for the shipping street-address field, preventing data overlap and facilitating reliable autofill functionality.

Beyond user-facing fields, the implementation of autocomplete can also extend to providing context hints to the browser, even if the input field itself is hidden. For instance, using a hidden input with autocomplete="transaction-currency" can hint to the user agent about the transactional context. While not strictly mandated by 1.3.5 (as it doesn't collect user data), this practice allows the browser to offer smarter, context-aware suggestions (e.g., suggesting a saved credit card known to support the specified currency), thereby maximizing the overall effectiveness and reliability of the mandated user-specific autofill features.

Section 6: Compliance Assurance, Failures, and Maintenance

6.1 Common WCAG Failure: F107 (Incorrect autocomplete Values)

The primary technical failure condition related to SC 1.3.5 is documented as F107: Failure of Success Criterion 1.3.5 due to incorrect autocomplete attribute values. This failure is usually symptomatic of violating the rigid requirements of the WHATWG token specification.

F107 occurs under several circumstances:

1. Usage of Custom Tokens: The criterion mandates adherence to the fixed vocabulary. The introduction of non-standard, custom token values, even if seemingly descriptive, fails to meet the programmatic determination requirement based on the standard W3C/HTML vocabulary.
2. Incorrect Ordering: Violating the required sequence of Section -> Context -> Core Field Name tokens renders the programmatic determination ambiguous or unusable for user agents, leading to failure.
3. Typographical Errors: Misspelling or incorrect capitalization of predefined tokens is non-compliant, as token matching is based on specific ASCII case-insensitive comparisons against the standard list.

The enforcement rule requires that the autocomplete attribute value be a space-separated list that strictly conforms to the Autofill detail tokens structure, thus making deviations from the standard token set or order non-compliant.

6.2 Anti-Patterns: Relying on Non-Semantic Elements

Achieving programmatic determination necessitates the explicit use of standardized semantic attributes. Several common development practices fall short of meeting 1.3.5 requirements:

• Reliance on Placeholders: Placeholders are often visually transient, disappear upon user input, and do not provide the necessary programmatic identification layer. They cannot substitute for either a visible label or the required autocomplete attribute.
• Inferring Purpose from name or id: While some older browser heuristics may attempt to guess the field purpose based on the values of name or id attributes, this behavior is unreliable and does not satisfy the standardized programmatic determination requirement established by 1.3.5.

6.3 Multi-Technology Compliance and Standardization Parity

While the majority of web content compliance focuses on the HTML autocomplete attribute, SC 1.3.5 is technology-agnostic at its core. The criterion mandates that the purpose be programmatically determined, regardless of the underlying technology used for implementation. Consequently, other platforms and frameworks must provide an analogous mechanism that maps local field definitions to a standardized semantic taxonomy. For example, mobile development frameworks like Android utilize the android:autofillHints property, which requires values such as emailAddress, postalCode, or creditCardNumber to achieve semantic parity with the web standard and ensure accessibility compliance. This reinforces that the principle of a fixed, universally understood input purpose taxonomy is crucial across all digital platforms.

Conclusion and Auditing Summary

WCAG Success Criterion 1.3.5, Identify Input Purpose, represents a critical element of modern accessibility standards, particularly for enhancing cognitive and motor accessibility. Compliance is achieved through precise technical implementation: leveraging the HTML autocomplete attribute and strictly adhering to the ordered token hierarchy defined by the WHATWG standard.

This report establishes that the semantic layer provided by autocomplete is not merely a convenience feature but a mandatory mechanism that enables user agents and assistive technologies to perform automated data entry, resolve form ambiguities, and present customized visual modalities. Failure to implement the token structure correctly, especially regarding the ordered use of section-*, shipping/billing, and the Core Field Name tokens, constitutes a critical failure (F107) and breaks the essential programmatic link required for user assistance. For accessibility professionals and developers, mastering the nuances of this token taxonomy is fundamental to building universally usable forms.

Compliance Checklist for SC 1.3.5 (Level AA)

Table 2: SC 1.3.5 Compliance Checklist