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.
Top comments (1)
같은 type=email이라도 본인 연락처와 동료 초대 주소는 입력 목적이 다르다는 구분이 핵심이네요. 초대 칸에 본인 주소가 자동완성되지 않는지 확인하고, 키보드·스크린리더로 각 라벨의 의미가 구분되는지도 함께 시험하면 실제 오발송 위험을 줄이는 데 도움이 되겠습니다.