In one paragraph
Autocomplete attribute must be used correctly means a declared field-purpose hint failed this rule's validation. Use supported tokens that match the information requested and the permitted token order, rather than inventing field names. Keep a visible, associated label as well. Valid autocomplete can support personalisation and autofill, but neither a passing token check nor a missing attribute alone determines complete form accessibility.
Why it matters
WCAG 1.3.5 addresses programmatically identifying supported input purposes for information about the user, where the technology supports that identification. It does not require every search field or arbitrary message box to receive a made-up autocomplete token.
HTML provides a fixed vocabulary such as given-name, email, postal-code, and current-password. Structured combinations can distinguish sections or address contexts. The hint describes meaning; it does not replace validation, accessible naming, or correct input type.
An unrecognised value does not guarantee that all autofill stops: browsers and password managers can use other heuristics. Conversely, a valid hint does not force every client to fill the field. Describe intended semantics rather than promising a universal browser outcome.
How WebAuditOS evaluates this finding
The supplied axe-backed rule validates applicable autocomplete attributes that are present. It is not a completeness test for every field that might need a purpose hint. The documented integration maps serious impact to high severity, and reports violations rather than treating every unreported state as a conformance certificate.
Accepted exceptions, applicability, and token validation depend on the deployed axe version. A field without the attribute can escape this particular finding even when its purpose still needs review. A syntactically accepted value can also describe the wrong information.
How to fix it
- Read the field's actual question and identify whose information it collects. Distinguish the user's own details from another recipient, a reusable credential, and a non-user-specific query.
- Select a defined supported purpose. For example:
<label for="given-name">First name</label>
<input id="given-name" name="givenName" autocomplete="given-name">The visible label may be translated; the machine token remains the defined vocabulary. Keep the name attribute used by your backend independent from autocomplete semantics.
- Use correct combinations for repeated address groups where appropriate, such as section and shipping or billing tokens in their specified order. Consult the HTML vocabulary rather than concatenating plausible-looking terms.
- For sign-in, review username and current-password; for a replacement password use new-password as appropriate. Do not label an API secret as the user's current site password simply because the input is masked.
- Preserve native labels and instructions. A valid autocomplete value does not tell every visitor what to enter and does not identify required fields or error messages by itself.
- Fix the shared form component and inspect its actual rendered attributes. A component can emit a custom prop incorrectly or override it after hydration. Test repeated sections and translated routes, not only one input.
- Exercise representative browsers and password managers with safe test data. Confirm fields receive the intended value, remain understandable after filling, and do not accidentally collect another credential.
- Rescan and separately review missing-purpose cases. A decision to use off should be justified by purpose, not treated as a reliable ban on password saving or a substitute for secure device handling.
What the fix can break
A wrong but valid token can fill the wrong value, creating privacy or usability problems. Correct token semantics matter more than merely avoiding a parser warning.
Form-library changes can affect every route. Preserve submission names, validation, and server expectations while changing the hint.
Do not add invented values to fields outside the defined purposes just to appear thorough. Unsupported taxonomy does not become useful by passing through a CMS unchanged.
Questions
Does every input require autocomplete?
No. Apply the purpose requirement to its actual scope and supported purposes. This rule validates present attributes rather than all omissions.
Is autocomplete off a security control?
Do not rely on it as one. Browser and password-manager behaviour varies, particularly for credentials.
Can a correct token replace a label?
No. Purpose metadata and a usable visible, associated label solve different needs.
Which related checks help?
Review form labels and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core, so a failure arrives as high. That is why the panel above states a conformance level rather than a severity - for other axe rules it depends on what failed.