autocomplete值必须严格遵循whatwg规范，如email、tel等，错误值会被视为off；需与type属性配合（如type="email"+autocomplete="email"），并保持字段语义顺序连贯，禁用off反而损害认知障碍用户可用性。
autocomplete值必须匹配WHATWG规范才能被屏幕阅读器识别
浏览器和辅助技术（如NVDA、VoiceOver）依赖autocomplete的语义值判断字段用途，不是靠name或placeholder猜。写错值（比如autocomplete="user-email"）会被当作off处理，导致屏幕阅读器无法播报“这是邮箱字段”，用户只能听到“编辑文本”这种无意义描述。
常见有效值包括：email、given-name、family-name、tel、street-address、postal-code、current-password、new-password。这些在WHATWG HTML标准中明确定义，且被主流辅助工具支持。
- 避免自造词：如
autocomplete="mobile"或autocomplete="zip"—— 不被识别 - 区分大小写不敏感，但连字符必须准确：
postal-code✅，postalcode❌ - 密码字段必须用
current-password或new-password，写password会被忽略
type + autocomplete组合影响移动端键盘与语音输入适配
仅设autocomplete="email"不够，还需配合type="email"。否则iOS VoiceOver可能不触发邮箱专用键盘，Android TalkBack也无法关联语义与输入法建议。两者缺一，认知障碍用户就少一层上下文提示。
同理：type="tel" + autocomplete="tel" 触发数字键盘；type="search" + autocomplete="on" 激活搜索历史语音联想。浏览器不是单看一个属性做决策。
- 不要只改
autocomplete而忽略type：比如把邮箱字段设为type="text"，即使autocomplete="email"，iOS也不会弹出@符号快捷键 -
type="text"配任意autocomplete值，都默认启用全键盘，对运动障碍用户更难操作 - 动态切换
type（如密码显隐）时，务必同步更新autocomplete值，否则辅助工具状态不同步
表单字段顺序与autocomplete逻辑链决定辅助技术是否启用上下文推断
屏幕阅读器和自动填充引擎都依赖字段间的语义序列。比如连续出现autocomplete="given-name" → autocomplete="family-name" → autocomplete="email"，辅助工具会推断这是一个注册流程，并提前告知“接下来是邮箱地址”。但如果中间插了一个autocomplete="organization"，整条链就断裂，后续字段降级为普通文本框。
这不是浏览器bug，而是可访问性设计原则：结构化语义必须连贯，才能支撑认知负荷较重用户的理解路径。
- 避免在关键字段间插入无语义或错配的
input（如隐藏的 tracking 字段） - 多步骤表单中，每步的
autocomplete应构成独立逻辑组，不要跨步混用 - 用
fieldset+legend包裹语义组，能强化辅助工具的分组感知，比单纯依赖autocomplete更可靠
autocomplete="off"对认知障碍用户反而降低可用性
禁用自动完成常被当成“安全措施”，但它对记忆困难、注意力分散或执行功能障碍用户是反模式。他们依赖浏览器历史补全来减少短时记忆负担，autocomplete="off"强制每次重输，显著增加操作失败率。
真正需要的是精准语义控制，而非粗暴关闭。例如支付页的卡号字段应设autocomplete="cc-number"，而不是off——既满足PCI合规，又让辅助工具明确播报“信用卡号码”，而非让用户盲猜。
- 敏感场景优先用语义值（如
cc-exp、cc-csc），而非off - 一次性验证码等真不需要补全的字段，用
type="text"+autocomplete="one-time-code"（Chrome 108+ 支持），比off更符合ARIA实践 - 如果必须关，至少保留
autocomplete="off"在input上，别写在form上——HTML5已废弃form级该属性，写了也无效
autocomplete值没写对、没配对、没排对，再好的屏幕阅读器也只能瞎猜。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
