The 2025 TestParty Guide to WCAG 1.3.5 – Identify Input Purpose (Level AA)

Why did the form field go to therapy? Because it had an identity crisis—nobody could tell what its purpose was! 🎭

WCAG 1.3.5 requires that the purpose of input fields collecting user information be programmatically identifiable using standardized HTML attributes. This lets browsers, password managers, and assistive technologies help users autofill forms accurately—a critical feature for people with cognitive disabilities, motor impairments, or anyone who struggles with repetitive data entry.

Table of Contents

• What WCAG 1.3.5 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 1.3.5
• How TestParty Helps
• FAQs

What WCAG 1.3.5 Requires

WCAG 1.3.5 mandates that when an input field collects information about the user, its purpose must be programmatically determinable. In practice, this means using the HTML autocomplete attribute with standardized values from the WCAG/HTML specification.

Key requirements:

• The input field must collect information about the user (not about other people, products, or entities)
• The field's purpose must match one of the 53+ standardized input purposes defined by WCAG (name, email, address, phone, credit card, etc.)
• You must use the HTML autocomplete attribute with valid token values
• The technology you're using must support programmatic identification (HTML5 does; most modern frameworks do)

What's covered:

Common fields like name, email, tel, street-address, postal-code, cc-number, bday, and username all have standardized autocomplete values.

What's NOT covered:

• Fields collecting information about someone other than the user (e.g., "recipient's address" on a gift form)
• Fields for non-personal data (product names, search queries, feedback comments)
• Custom business data that doesn't map to a standardized input purpose

Why This Matters

For users with cognitive disabilities, memory impairments, or dexterity challenges, filling out forms can be exhausting or impossible. Proper autocomplete attributes let browsers and assistive technologies autofill fields accurately, reducing cognitive load and errors.

Legal and compliance context:

WCAG 1.3.5 is a Level AA requirement, making it mandatory for ADA Title II and Title III compliance, Section 508 federal procurement, EN 301 549 (European public sector), and the European Accessibility Act. Organizations that fail to implement proper input purpose identification risk legal complaints, especially in checkout flows, account creation, and government service portals.

Business benefits:

Autofill increases form completion rates, reduces cart abandonment, and improves user satisfaction. Google reports that proper autocomplete can reduce checkout time by up to 30%. It's a rare accessibility win that directly boosts conversion.

Quick Implementation Guide

Add the autocomplete attribute to every input field that collects user information. Use the standardized token values from the WCAG/HTML spec.

Basic example:

<!-- Contact form -->
<label for="fullname">Full Name</label>
<input type="text" id="fullname" name="fullname" autocomplete="name">

<label for="email">Email Address</label>
<input type="email" id="email" name="email" autocomplete="email">

<label for="phone">Phone Number</label>
<input type="tel" id="phone" name="phone" autocomplete="tel">

<!-- Shipping address -->
<label for="address">Street Address</label>
<input type="text" id="address" name="address" autocomplete="street-address">

<label for="city">City</label>
<input type="text" id="city" name="city" autocomplete="address-level2">

<label for="zip">ZIP Code</label>
<input type="text" id="zip" name="zip" autocomplete="postal-code">

<label for="country">Country</label>
<select id="country" name="country" autocomplete="country">
  <option value="US">United States</option>
  <!-- more options -->
</select>

Key techniques:

• H98: Using HTML autocomplete attributes with standardized values
• Use autocomplete="off" sparingly—only for fields where autofill would be inappropriate (e.g., one-time codes, CAPTCHA)
• For multi-part names, use given-name and family-name instead of generic name
• For addresses, use specific tokens like address-line1, address-line2, address-level1 (state), address-level2 (city)

Checkout and payment forms:

Use cc-name, cc-number, cc-exp, cc-csc, and cc-type for credit card fields. This enables secure autofill from password managers and browser payment APIs.

Common Mistakes to Avoid

Using incorrect or non-standard autocomplete values:

autocomplete="fullname" is invalid—the correct value is name. autocomplete="phone-number" is wrong; use tel. Browsers ignore invalid values, breaking autofill.

Omitting autocomplete entirely:

Many developers skip the attribute, assuming browsers will "figure it out." They won't—at least not reliably. Explicit is better than implicit.

Applying autocomplete to non-user fields:

Don't use autocomplete="name" on a "gift recipient name" field. That field collects information about someone else, not the user. WCAG 1.3.5 only applies to fields about the user.

Disabling autofill for security theater:

Some sites disable autocomplete on password or credit card fields, thinking it's more secure. Modern password managers and browser payment APIs are more secure than users retyping credentials. Disabling autofill harms accessibility and security.

How to Test for WCAG 1.3.5

Automated checks:

• Use an accessibility scanner (axe, WAVE, Lighthouse, or TestParty) to detect missing or invalid autocomplete attributes on common input types
• Automated tools can flag fields with type="email" or type="tel" that lack corresponding autocomplete values
• Tools can validate that autocomplete values match the WCAG/HTML spec

Manual checks:

• Inspect the HTML source or use browser DevTools to verify autocomplete attributes are present and correct
• Test autofill in Chrome, Safari, or Firefox—does the browser suggest appropriate values?
• Use a screen reader (NVDA, JAWS, VoiceOver) with a form-filling tool to confirm assistive tech can parse the input purpose

Checklist:

• [ ] Every input collecting user information has an autocomplete attribute
• [ ] Autocomplete values match the WCAG Input Purposes list
• [ ] Browser autofill works as expected (test in Chrome and Safari)
• [ ] Password managers correctly identify and fill fields

How TestParty Helps

TestParty's automated scanning and AI-powered remediation make WCAG 1.3.5 compliance straightforward, even across large sites with hundreds of forms.

What TestParty detects:

TestParty scans your HTML and JavaScript-rendered DOM to identify input fields that collect user information but lack autocomplete attributes. It flags:

• Email, phone, and URL inputs without corresponding autocomplete values
• Text inputs with labels or names suggesting personal data (name, address, city, ZIP, birthday) but missing autocomplete
• Payment forms missing cc-* autocomplete tokens
• Invalid or non-standard autocomplete values (e.g., autocomplete="fullname" instead of name)

TestParty's semantic analysis goes beyond simple pattern matching—it uses AI to infer field purpose from labels, placeholders, and surrounding context, catching fields that manual audits often miss.

How TestParty suggests fixes:

When TestParty detects a missing or incorrect autocomplete attribute, it generates a code-level fix. For example:

• <input type="email" name="email"> → <input type="email" name="email" autocomplete="email">
• <input type="text" name="zip"> → <input type="text" name="zip" autocomplete="postal-code">

These fixes are presented as diffs or patches that developers can review and approve before merging. TestParty doesn't deploy changes automatically—human oversight ensures fixes are contextually appropriate (e.g., confirming a "name" field is for the user, not a gift recipient).

For sites built on templating systems (Shopify themes, WordPress, React components), TestParty suggests fixes at the template or component level, so corrections cascade across all instances.

Developer workflow integration:

TestParty integrates into your CI/CD pipeline and pull request workflow:

• Pre-commit hooks and IDE plugins surface missing autocomplete attributes as developers write code
• CI/CD gates block merges if critical forms (checkout, account creation) lack proper input purpose identification
• Pull request annotations show line-by-line suggestions with explanations of why each autocomplete value is required

This "shift-left" approach catches 1.3.5 violations before they reach production, preventing regressions as new forms are added or updated.

Ongoing monitoring:

TestParty continuously monitors your site for new or modified forms, flagging any that introduce WCAG 1.3.5 violations. Dashboards track compliance over time, showing which pages have been remediated and which still need attention.

Audit-ready reports document your autocomplete implementation for legal reviews, procurement requirements, or accessibility statements. TestParty's embedded guidance explains why each autocomplete value matters, helping teams build institutional knowledge.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.

FAQs About WCAG 1.3.5

What is WCAG 1.3.5 in plain language?

WCAG 1.3.5 requires that form fields collecting user information (like name, email, or address) use the HTML autocomplete attribute so browsers and assistive technologies can help users fill them out automatically. This reduces errors and cognitive load, especially for people with disabilities.

Is WCAG 1.3.5 required for ADA compliance?

Yes. WCAG 1.3.5 is a Level AA criterion, and ADA Title II and Title III digital accessibility compliance typically requires meeting WCAG 2.1 or 2.2 Level AA. Federal agencies must also meet it under Section 508, and it's mandatory under EN 301 549 and the European Accessibility Act.

Do I need autocomplete on every input field?

No—only on fields that collect information about the user and match one of the 53+ standardized input purposes (name, email, phone, address, payment details, etc.). Fields for search queries, product names, or information about other people are exempt.

Can I use `autocomplete="off"` for security?

Use it sparingly. Disabling autofill on passwords or payment fields often harms both accessibility and security—modern password managers and browser payment APIs are more secure than manual entry. Only disable autofill for one-time codes, CAPTCHA, or fields where autofill would be contextually inappropriate.

What are the most common autocomplete values?

The most frequently used values are name, email, tel, street-address, address-level1 (state), address-level2 (city), postal-code, country, cc-name, cc-number, cc-exp, cc-csc, username, and current-password. See the full list in the WCAG spec.