aria-describedby 必须通过唯一 ID 精确引用已存在且未隐藏的目标元素，ID 拼写、大小写、DOM 存在性及生命周期均需严格校验；它仅传递描述文本，不触发错误语义或播报，错误提示需配合 aria-invalid 与 aria-errormessage。
aria-describedby 必须用 ID 显式引用已有 DOM 元素
它不是“自动找旁边文字”，而是靠 id 精确绑定——目标元素必须真实存在、有唯一 id、且不能被 display: none 或 aria-hidden="true" 隐藏。常见失败现象：屏幕阅读器静默、读出错误内容、或根本没读，90% 是因为 id 拼错、大小写不一致（email-error ≠ Email-Error）、或目标元素还没挂载到 DOM 就设置了 aria-describedby。
- 目标元素推荐用
<p>或<div>，避免用语义太弱的<span> - ID 值应语义化，比如
password-hint比hint1更易维护和调试 - 多个描述可用空格分隔：
aria-describedby="email-hint email-error"，朗读顺序按 DOM 中元素出现顺序 - 若描述文本需视觉隐藏但供读屏使用，用
class="sr-only"（配合clip-path或position: absolute），别用display: none
表单控件中，aria-describedby 和 label 职责必须分离
label 定义控件“是什么”，aria-describedby 补充“怎么用”或“要注意什么”。两者共存是常态，但混用会出问题：比如把提示文字塞进 <label> 里再额外加 aria-describedby，会导致重复朗读；更严重的是，用 aria-describedby 替代 label，会让无 CSS 场景下完全不可见，也绕过浏览器原生校验逻辑。
- 输入框必须有自己的
id，<label for="xxx">指向它，而不是反过来让控件指向label的id - 适合用
aria-describedby的内容：格式示例（“如：name@example.com”）、字符限制（“最多 50 字符”）、业务规则（“仅限中国大陆手机号”） - 不适合的内容：“用户名”“密码”这类核心标识词——这些必须由
label承担
动态更新时，ID 生命周期比内容更新更重要
JS 插入错误提示后只改 textContent 不够，如果 id 是随机生成（如 error-uuid4()）或组件销毁时未清理，下次校验就会找不到目标。屏幕阅读器不报错，只是默默跳过关联。
- 服务端渲染或初始 HTML 中就该预置空容器：
<p id="email-error" class="sr-only" aria-live="polite"></p> - 客户端 JS 更新时，只操作
textContent或innerText，不要删重建元素 - ID 命名建议带字段标识，如
error-email；列表场景下加唯一 key，如error-user-0-email - 设置属性前，先用
document.getElementById("email-error")确认存在，再调input.setAttribute('aria-describedby', 'email-hint email-error')
错误播报不靠 aria-describedby，而靠 aria-invalid + aria-errormessage
aria-describedby 本身不触发错误语义——它只是把文字“连过去”，读出来而已。用户听不出这是错误，也不会中断当前播报。真正让屏幕阅读器识别为“需紧急处理”的，是 aria-invalid="true" 加 aria-errormessage="xxx" 的组合。
立即学习“前端免费学习笔记（深入）”；
- 错误场景必须同时设：
aria-invalid="true"+aria-errormessage="email-error"（注意不是aria-describedby） -
aria-describedby可保留，用于挂格式提示等非错误信息，形成“提示 + 错误”双通道 - 错误容器建议加
role="alert"或aria-live="polite"+role="status"，否则动态更新后可能不播报 - DOM 顺序上，错误容器尽量放在输入框后紧邻位置，方便视觉定位与可访问性树遍历
aria-describedby 当成“万能提示开关”——它只管连接，不管状态、不触发播报、不处理生命周期。错把责任全压给它，反而会让无障碍体验变得更糟。 
