WCAG 2.1 · Level AA · Perceivable
WCAG 1.3.5 — Identify Input Purpose, explained with examples
Inputs collecting common personal information must have a programmatic purpose set, typically via the autocomplete attribute. Allows browsers and assistive tech to autofill, customize labels, and offer symbol-based help.
- Number
- 1.3.5
- Level
- AA
- Principle
- Perceivable
- Guideline
- 1.3 Adaptable
Why this criterion exists
Allows browsers and assistive tech to autofill, customize labels, and offer symbol-based help.
If you only remember one thing: inputs collecting common personal information must have a programmatic purpose set, typically via the autocomplete attribute. Everything else on this page is detail.
Who feels it when this fails
Accessibility criteria sometimes feel abstract until you see who pays the cost when a site ignores them. Identify Input Purpose affects:
Cognitive accessibility
Older users
Mobile users
How sites typically fail it
These are the patterns we see week after week. None are intentional — they are accidents of how teams build interfaces under deadline. Knowing the failure modes is the fastest path to writing them out of your component library.
Email input without autocomplete="email"
Address fields without autocomplete tokens
How to test for it
Inspect personal-data inputs for autocomplete tokens.
Automated scanners catch this criterion most of the time, but never all of the time. Manual testing with the keyboard and a screen reader closes the gap.
A code fix you can copy
Use the standard autocomplete tokens defined in HTML5 (email, family-name, postal-code, etc).
The problem
<input type="email" id="email">The fix
<input type="email" id="email" autocomplete="email">
<input type="text" id="ln" autocomplete="family-name">Use the standard autocomplete tokens defined in HTML5 (email, family-name, postal-code, etc).
Other Perceivable criteria
Find every accessibility issue on your site in 60 seconds.
Free public scan. No card. AI-generated fixes for every issue we find.