用户已经在浏览器保存了姓名、邮箱、地址，却在企业网站每次重新输入，往往不是浏览器能力不够，而是字段没有提供机器可理解的输入目的。Autocomplete 可以同时提高效率、减少输入错误，并帮助部分认知障碍用户。
01 WCAG 1.3.5 的重点是让常见个人信息输入目的可程序识别
W3C 当前 Identify Input Purpose 文档要求，在收集用户信息的字段符合定义场景时，输入目的应能被程序确定。HTML autocomplete token 是常见实现方式。
这不仅服务浏览器 Autofill，也可以让辅助工具提供图标、语言或更适合用户的输入帮助。
02 设计师需要给字段稳定语义，开发才能正确标记
“联系信息”到底是工作邮箱还是任意邮箱？“姓名”是完整姓名还是姓/名分开？如果产品定义模糊，autocomplete 也无法正确。
字段语义应该在设计需求中写清，而不是开发上线前自己猜 token。
03 常见字段应该使用标准 token，而不是自造属性
name、given-name、family-name、email、tel、street-address、postal-code 等已经有标准化值。
正确使用能让浏览器理解不同字段关系，尤其是长地址和结账表单。
04 “autocomplete=off”并不是解决所有错误填充的万能方式
有些团队因为一次 Autofill 样式难看就全站关闭，用户只能反复手输。浏览器也可能在登录等场景基于安全和用户偏好采取自己的策略。
应该先修字段语义、name 和表单结构，只有确实不应保存的特殊输入再谨慎处理。
05 一次性验证码也可以借助输入语义减少复制操作
移动端收到短信 OTP 时，正确标记 one-time-code 可以让系统提供验证码建议，减少来回切换。
同时仍要允许粘贴和密码管理器，不要用拆成 6 个独立框并禁止粘贴的交互制造障碍。
06 自动填充后的视觉状态要保证可读
浏览器 Autofill 可能改变背景色，深色主题尤其容易出现文字对比问题。
设计验收要实际测试 Chrome、Safari 等自动填充状态，而不是只看空表单设计稿。
07 敏感字段需要考虑安全和用户预期
银行卡、安全码、身份证等数据是否允许保存需要结合浏览器安全模型和业务法规。
不能因为 Autocomplete 能提高效率，就默认所有敏感信息长期记忆。
08 好的表单让用户尽量少输入，而不是展示更多控件
自动填充、合理默认值、地址联想和扫描都属于减少输入成本。
当系统已经知道用户账户信息时，更应避免重复询问。Autocomplete 是其中最基础、成本最低的一层。
09 字段 Label 和 autocomplete 解决的是不同问题
可见 Label 帮用户理解“这里要填什么”，autocomplete 则给浏览器和辅助技术机器可读的输入目的。只写 placeholder 不能替代这两者。
例如“工作邮箱”仍需要明确 Label；如果字段符合标准用途，再配置合适 autocomplete token，浏览器才更容易正确提供建议。
10 自动填充后的状态也要测试视觉与校验逻辑
浏览器可能一次填入姓名、地址和电话。若表单只在用户逐字输入时触发校验，自动填充后按钮仍保持 Disabled，就会形成隐蔽 Bug。
同时要检查浏览器自动填充背景色是否让文字或边框看不清，尤其是深色主题和品牌自定义输入框。
常见问题
Autocomplete 和 Placeholder 是一回事吗？
不是。Placeholder 是视觉提示，autocomplete 是告诉浏览器字段输入目的的机器可读语义。
所有字段都需要 autocomplete 吗？
标准个人信息和常见输入尤其有价值，自定义业务字段不一定有对应 token。
可以全站 autocomplete=off 吗？
不建议作为默认策略，会损失填写效率和可访问性。
验证码输入可以自动填吗？
支持平台上可使用 one-time-code 等语义，同时应允许正常粘贴和辅助输入。
设计师需要关心 HTML 属性吗？
需要理解其体验影响，并在交付中定义字段语义，具体代码由开发实现。
相关服务与进一步咨询
链接复制成功
