- Success Criterion 1.3.5
- Conformance level AA
Custom Form Widget That Drops the Native Autocomplete Behavior
1.3.5 — Identify Input Purpose
Scenario
Setting
A news outlet's article page
What’s wrong
Custom JS widgets replacing native inputs (framework "smart fields") that drop the underlying autocomplete/purpose semantics.
Example
<input type="text" name="email"> Why it matters
People with motor or cognitive disabilities who rely on browser autofill for personal data.
How to test
Inspect a custom-built 'smart field' component in DevTools: check whether the rendered input still carries the correct native autocomplete attribute, or whether the framework stripped it.
How to fix
The field must carry the correct, valid autocomplete token (code telling browsers what the field collects) for its purpose so browsers and assistive tools can identify and autofill it.
<input type="text" name="email" autocomplete="email">autocomplete lets browsers and AT identify common input purposes and offer autofill support.
Outcome
On a news outlet's article page, this barrier is gone for people with motor or cognitive disabilities who rely on browser autofill for personal data — they get the same result as anyone else here.
Who is affected
People with motor or cognitive disabilities who rely on browser autofill for personal data.
Learn more
- Understanding Understanding document (opens in a new tab)
Related scenarios
- Autocomplete Attribute Set to the Wrong Value for the Field
- Personal-Data Field With No Autocomplete Attribute at All
- Autocomplete Deliberately Disabled on a Personal-Data Field
- Autocomplete Token Placed on the Wrong HTML Element
- Autocomplete Section Token Used Incorrectly, Breaking Its Value
- Login or Checkout Iframe That Strips Out Autocomplete Support