aria-label只适用于无可见文本但需屏幕阅读器朗读的交互元素，如纯图标按钮、无label的搜索框、伪按钮；不可用于div/span等非交互容器，也不能与可见文本或aria-labelledby共存，否则会覆盖原内容或失效。
aria-label 只该用在**没有可见文本、又需要被屏幕阅读器朗读**的交互元素上，加错位置或滥用反而会让内容“消失”。
哪些元素适合加 aria-label
它不是万能补丁，只解决“有功能但没文字”的问题：
-
<button>里只有图标（如<button><svg>...</svg></button>），就该加aria-label="删除" - 纯
<input type="search">没配<label>，且上下文不足以推断用途时，可用aria-label="搜索网站" - 自定义
<div role="button">或<span tabindex="0">这类伪按钮，必须配aria-label，否则屏幕阅读器直接跳过 -
<div>、<span>等非交互容器**不能单独加aria-label**——它们默认不可聚焦，读屏器通常不读；非要这么做，得同时加role="button"和tabindex="0"，但这暴露了语义缺陷，不如直接换<button>
哪些情况绝对不能用 aria-label
它会**完全覆盖元素内部文本**，一旦写错，用户听到的就不是你期望的内容：
-
<button aria-label="提交">发送</button>→ 屏幕阅读器只读“提交”，“发送”被静音 -
<input aria-label="邮箱">和旁边已有<label for="email">邮箱地址</label>共存 →aria-label优先级更高，<label>形同虚设 - 表单控件（
<input>、<select>）已有<label>关联，再加aria-label属于冗余，Lighthouse 会报错 - 多语言站点里把
aria-label写死成英文，比如aria-label="Close"，后续翻译系统无法同步更新
aria-label 和 aria-labelledby 怎么选
核心判断标准：页面上**有没有现成的、可见的、可访问的文本**？
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 有 —— 用
aria-labelledby，指向那个元素的id。例如：<label id="search-label">查找商品</label>+<input aria-labelledby="search-label">。文案改了、翻译切了，读屏内容自动同步 - 没有 —— 才用
aria-label，比如关闭弹窗的 × 按钮、加载中的 spinner 图标 - 两者**不能共存**：
aria-labelledby会直接忽略aria-label，写了也白写 - 别指望
placeholder替代：placeholder="请输入邮箱"不是标签，输入后就消失，且部分读屏器根本不识别它
容易被忽略的细节和验证方式
最常出问题的地方不在“加没加”，而在“加得对不对”：
- ID 拼错、目标元素被
display: none或aria-hidden="true"隐藏 →aria-labelledby引用失败，整个控件对读屏器失联 - 多个 ID 必须空格分隔：
aria-labelledby="id1 id2"，写成aria-labelledby="id1,id2"（逗号）就无效 - 验证不能只看代码：打开 NVDA + Firefox 或 VoiceOver + Safari，实际听一遍播报内容；别信“开发者工具里属性存在”，要信“耳朵听到什么”
- 动态渲染场景下，ID 对应的元素可能还没挂载到 DOM，或 JS 临时移除了它 —— 这类 bug 很难复现，但真实影响键盘用户
真正难的不是加属性，而是判断“这个元素到底需不需要被读出来”以及“它该读哪段话”。很多无障碍问题，根源是 UI 设计阶段就没考虑语音流路径。
