HTML5的placeholder不支持密码提示语义化定制，应改用aria-describedby+独立提示区块实现可访问、可动态更新的引导方案。
HTML5 的 placeholder 属性本身不支持“密码提示语”的语义化定制——它只是纯文本占位符，且在 中默认会隐藏真实内容，但 placeholder 文本仍以明文显示（无掩码）。所谓“友好引导”，关键不在改 placeholder 本身，而在于绕过它的局限性做合理增强。
为什么直接改 placeholder 不解决“密码提示”问题
浏览器对 type="password" 的 placeholder 渲染是受限的：它不会随输入状态动态变化，无法区分“未输入”“格式错误”“确认不一致”等场景；且一旦聚焦输入框，placeholder 消失，用户立刻失去上下文引导。更严重的是，部分旧版 Safari 和 Android WebView 会把 placeholder 文本也模糊渲染（类似密码点），导致文字不可读。
常见错误现象包括：
-
placeholder写成 “••••••” 或 “请输入密码” —— 前者用户根本看不懂，后者毫无约束提示 - 用 CSS 强行修改
::placeholder颜色/字体，却忽略 iOS Safari 对伪元素的支持差异 - 把密码强度规则全堆进
placeholder，如 “8-20位，含大小写字母+数字+符号” —— 超出空间、可读性差、无法交互
用 aria-describedby + 独立提示区块替代 placeholder
真正可访问、可维护、能动态更新的密码引导，应脱离 placeholder，改用 ARIA 标准方案。核心是让屏幕阅读器和视觉用户都看到实时反馈，同时保持表单语义清晰。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 给密码输入框添加
id="pwd-input"和aria-describedby="pwd-hint" - 在输入框下方紧邻位置放一个
，初始内容为通用提示，如 “至少8位，建议包含字母和数字” - 监听
input事件，根据正则匹配结果动态更新pwd-hint的 innerText 和aria-live属性（设为"polite"） - 避免使用
title属性做提示——它触发延迟、不可控、不支持键盘导航
示例片段：
至少8位，含大小写字母和数字
密码确认框必须单独配提示，且要双向校验
很多开发者只在第一个密码框加提示，却让确认框（type="password" + name="confirm_password"）仅靠 placeholder="再次输入" 敷衍。这会导致用户输错后无法定位是“首填错”还是“确认错”。
正确做法：
- 确认框也绑定独立提示区，
id="confirm-hint"，初始提示为 “请与上方密码完全一致” - 监听两个框的
input事件，只要任一值变更，就比对两者值是否相等，并更新对应提示区文本 - 若不一致，
confirm-hint显示 “⚠ 不匹配，请检查”，同时给首密码框加aria-invalid="true"（如果它本身已通过基础校验） - 不要用
pattern或required强制两个框同时填满才校验——用户习惯先输完再确认，应支持渐进式反馈
移动端适配要点：别依赖 placeholder 占位空间
iOS 键盘弹出时，placeholder 可能被遮挡或缩放失真；Android 输入法也可能覆盖提示区域。此时独立提示区块若没做定位控制，会被挤出视口。
关键处理：
- 提示区块用
position: relative紧跟输入框，不依赖绝对定位或 fixed - 设置最小高度（如
min-height: 1.2em），防止文字换行时高度塌陷影响布局 - 对
input:focus + #pwd-hint添加轻微上移动画（transform: translateY(-2px)），提升视觉焦点关联感 - 禁用
user-select: none—— 用户可能想复制提示中的示例密码格式（如 “Abc123!@#”）
真正友好的密码引导，不是把字塞进 placeholder，而是让提示成为可感知、可响应、可操作的信息节点。最常被忽略的一点：所有提示文案必须通过 WCAG 2.1 AA 对比度检测（至少 4.5:1），否则色弱用户根本看不见那句“建议包含符号”。
