aria-describedby 不触发错误播报，因其仅关联描述文本而不携带语义状态；错误需 aria-invalid="true" 与 aria-errormessage 配合才能被屏幕阅读器识别为需紧急处理的问题。

aria-describedby 的作用不是显示错误提示，而是把输入框和**已存在的描述性文本元素**关联起来——错误提示必须单独用 aria-errormessage + aria-invalid="true" 才能被屏幕阅读器识别为错误。

为什么直接在 input 上写 aria-describedby="error-id" 不会触发错误播报？

因为 aria-describedby 本身不带语义状态，它只负责“读出那段文字”，不管内容是提示、格式说明还是错误。屏幕阅读器不会因此改变语气、中断流程或标记为错误；它只是平铺直叙地朗读。

• 错误需要明确的状态信号：aria-invalid="true" 是触发错误播报的关键开关
• 仅靠 aria-describedby 引用错误文本，相当于把错误消息当成普通提示——用户听不出这是要立刻处理的问题
• 部分旧版 NVDA 或 JAWS 在未设 aria-invalid 时，甚至会跳过该描述（尤其当焦点刚进入输入框时）

aria-describedby 和 aria-errormessage 必须配合使用的场景

表单验证失败后动态插入错误信息，且该信息不在 label 内、也不在输入框内部时：

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 错误容器需有唯一 id（如 email-error），不能复用提示 ID
• 输入框同时设置：aria-invalid="true" + aria-errormessage="email-error"（注意不是 aria-describedby）
• aria-describedby 仍可保留，用于引用格式提示（如 email-hint），形成“提示 + 错误”双信息流
• 示例：

  <input type="email" id="email" aria-invalid="true" aria-errormessage="email-error" aria-describedby="email-hint"><div id="email-hint">请输入公司邮箱地址</div>
  <div id="email-error">域名格式不正确，请使用 @example.com</div>

容易忽略的 DOM 更新时机问题

JavaScript 动态渲染错误信息后，如果没等元素挂载完成就设置 aria-errormessage，会导致屏幕阅读器找不到目标节点：

• 不要在 innerHTML = "...error..." 后立刻赋值属性；应确保元素已存在于 DOM 中
• 推荐用 document.getElementById("email-error") 检查是否存在，再设置 aria-errormessage
• 避免把错误文本塞进同一个 div 里反复修改 innerHTML —— 若该 div 曾被隐藏（display: none），部分屏幕阅读器可能缓存旧状态
• 更稳妥的做法：预先渲染空的 <div id="email-error" aria-live="polite"></div>，只更新其文本内容

真正决定错误是否被“当作错误播报”的，是 aria-invalid 和 aria-errormessage 这对组合；aria-describedby 只负责补充上下文，别让它承担本不属于它的责任。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！