An email field can have the right type and the wrong purpose

A contact form asks for a person's email address. Another field on the same page asks for the email address of a colleague to invite. Both fields might use type="email", but they do not collect the same information. The type describes the input format; it does not, by itself, say whose address belongs in the field.

W3C's Identify Input Purpose guidance makes that distinction explicit. For listed fields collecting information about the user, the purpose must be programmatically determinable where the technology supports it. HTML's autocomplete tokens can express a more specific purpose than the input type.

Map the purpose before changing markup

For a form that asks for the user's own email address, a developer can review whether autocomplete="email" represents that field. The colleague-invitation field needs separate consideration: assigning the user's email purpose to another person's address would misstate what the form asks for. Keep its visible label clear, but do not mechanically stamp the same autocomplete token onto every email-shaped field.

The same check matters for a name field. type="text" gives no indication whether the form expects a full name, given name, family name, or another person's name. W3C's fixed tokens include name, given-name, and family-name for different user-information purposes. A reviewer should identify the actual data the application stores before choosing one.

Test the resulting form

Inspect the rendered field and its accessible name, then check the relevant HTML attribute. Try the form in a browser with saved profile data only in an appropriate test environment. Confirm that the browser does not offer the user's own information in a field meant for someone else. Repeat the check after a source change, since a template can render different fields from similar components.

ADAFix website accessibility repairs describe a reviewed source-change and live-verification workflow. An input-purpose finding is a useful example of why the reviewer must connect the visible task to the exact field before approving a markup change. The final check is the live form's meaning and behavior, rather than a green scan result alone.