A developer building a signup form makes a small, well-intentioned decision: setting autocomplete="off" on every input, specifically to stop the browser's autofill dropdown from popping up and, in their view, cluttering the design. It feels like a cosmetic choice, the digital equivalent of turning off a notification popup. It is not cosmetic. Turning autocomplete off does not just suppress a visual dropdown. It removes a piece of machine-readable semantic information that a screen reader, a switch-access device, and every password manager on the page all depend on to understand what a given field is actually asking for.
The Stat: WCAG Success Criterion 1.3.5 Identify Input Purpose, a Level AA requirement since WCAG 2.1, requires common input fields to carry a correct autocomplete token so assistive technology and browser autofill can identify what the field is actually asking for. (Source: W3C WCAG 2.1, Success Criterion 1.3.5)
What autocomplete="off" Actually Tells the Browser
The autocomplete HTML attribute exists to declare a field's purpose in a standardized, machine-readable way: autocomplete="email" tells a browser and any assistive technology reading the page that this field expects an email address; autocomplete="given-name", a first name; autocomplete="street-address", a street address. This is not decoration. It is a formal, specified vocabulary, documented directly in the HTML standard, that any tool consuming the page can rely on to understand a field's purpose without needing to guess from a visible label alone, which is exactly what WCAG 1.3.5 requires for a defined list of common input types.
Setting the attribute to "off" does not merely leave this information blank. It is an explicit, affirmative instruction telling every consumer of the page, the browser's autofill engine, a password manager, and assistive technology alike, that this field's purpose should not be inferred or exposed through that channel at all.
Why This Specifically Hurts Screen Reader and Switch-Access Users
A sighted user filling out a form reads the visible label above each field and infers its purpose visually, even if that inference sometimes takes a moment. A screen reader user relies far more heavily on the field's programmatically exposed name and purpose, because that is what actually gets announced; a poorly worded or ambiguous visible label is already a common friction point, and the autocomplete attribute is one of the more reliable, standardized ways to remove that ambiguity entirely for input types the specification already defines. Suppressing it removes a genuinely helpful disambiguation signal specifically for the users who benefit from it most.
Switch-access and voice-control users face a related, distinct problem: many of these tools use the same semantic hints to offer users a shortcut, filling a "current password" field correctly without requiring the user to type it manually via a slow, effortful input method. Disabling autocomplete disables that shortcut along with the visual dropdown, adding real friction to exactly the group of users for whom that friction is most costly.
The Password Manager Problem Most Teams Do Not Even Realize They Caused
There is a second, non-accessibility-specific cost worth naming because it usually gets discovered independently, and often blamed on the wrong cause: autocomplete="off" also breaks password manager autofill for the entire form, not just the browser's native dropdown. A user with a password manager (a group that skews heavily toward users who also rely on assistive technology, since manually typing complex passwords is a friction point for many disability types as well) loses the ability to autofill their credentials at all, often without any obvious visual explanation for why, leading to abandoned signups that get attributed to "form friction" in analytics without anyone identifying the actual, specific cause.
Why This Pattern Is So Easy to Carry Forward Unquestioned
Part of what makes autocomplete="off" persistent across codebases is that it rarely causes an obvious, attributable bug report. A user whose password manager silently fails to autofill a form tends to describe the resulting friction as "this signup form was annoying" or simply abandons the flow, not "the autocomplete attribute was disabled," because most users have no reason to know the attribute exists at all. The same is true for the accessibility cost: a screen reader user navigating a form with no autocomplete hints does not file a bug report citing WCAG 1.3.5 by number, they simply find the form more effortful than it needed to be, or give up. Both costs are real and both are almost invisible in typical bug-tracking and analytics data, which is exactly why a setting like this, once added for a specific, narrow reason years earlier, tends to get copied into every new form a team builds afterward, unquestioned, long after the original reason for adding it has been forgotten.
A Related Trap: Custom Fields That Fight the Browser's Own Inference
A related, slightly subtler version of this problem shows up even without autocomplete="off" anywhere: a custom-styled dropdown or combobox standing in for what should be a plain <select> or <input> element for a common field like state or country. Even with a correct autocomplete token theoretically available, a heavily customized non-native input often cannot actually receive or expose it the way a native form control can, because the token is designed to work with real form-control semantics the custom component may not fully replicate. This is one more example of the same broader principle running through most of this site's UI-pattern coverage: a native HTML element carries a substantial amount of accessibility behavior for free, and a custom-built replacement inherits none of it automatically, no matter how visually polished the replacement looks.
What to Actually Do Instead
For the vast majority of forms, the fix is simply not setting autocomplete="off" at all, and instead applying the correct, specific token to each field: email, given-name, family-name, street-address, new-password for signup, current-password for login, one-time-code for a verification code field. The full list is defined directly in the HTML Living Standard and in WCAG's own input-purposes reference. The one legitimate, narrow exception is a field genuinely unlike anything in that defined vocabulary, a custom internal reference number, for example, where there is no meaningful autocomplete purpose to expose either way; even in that case, autocomplete is best left unset entirely rather than explicitly disabled, since an unset attribute simply defaults to no suggestion rather than actively suppressing one.
For the broader forms discipline this connects to, our 12-point accessible form checklist and our piece on labels, errors, and conversion-focused form design both cover the wider set of common form failures worth auditing alongside this one.
If your signup or checkout forms currently set autocomplete="off" anywhere, that is worth reviewing directly, since it is very often a leftover decision from years ago that nobody has revisited since. Our free accessibility tools can flag this pattern automatically, and our team is reachable directly at experts@wcag.world for a closer review of your specific forms. The W3C's Identify Input Purpose guidance and the full defined list of input purposes are both worth reading directly for the complete technical vocabulary.