aria-label仅在无可见文本且无法用label或aria-labelledby时使用，否则会破坏无障碍；有现成文本优先用aria-labelledby，二者共存时后者生效；标题、图片、带文本网钮等场景禁用aria-label。
aria-label 不是“加了就无障碍”，而是“加错就破坏无障碍”。它只在特定场景下有效，且极易覆盖本该被读出的文本。
aria-label 什么时候必须用？
只有当元素没有可见文本、又无法通过其他语义方式（如 <label>、aria-labelledby）提供可访问名称时，才考虑 aria-label。
- 纯图标按钮：
<button><svg></svg></button>，内部无文字，也不打算加视觉文案 - 封装严密的第三方组件中的输入框（比如搜索框只暴露一个
<input type="search">），且无法插入<label> -
<nav>等区域级容器需要区分多个同类元素，例如面包屑：<nav aria-label="Breadcrumb"> - 模态框标题未用
<h2>包裹，且无法修改 DOM 结构时，临时补位用aria-labelledby更合适，aria-label是次选
aria-label 和 aria-labelledby 怎么选？
核心判断标准就一条：页面里有没有现成的、可见的、语义匹配的文本？有，就用 aria-labelledby；没有，才用 aria-label。
-
aria-labelledby引用的是真实 ID，目标元素必须存在、可见、未被aria-hidden="true"或display: none隐藏 -
aria-labelledby支持空格分隔多个 ID：aria-labelledby="icon-desc name-cell status-badge"，读屏器按顺序拼接朗读 -
aria-label是硬编码字符串，不支持翻译或动态内容，维护成本高 - 两者同时出现时，
aria-labelledby优先级更高——但浏览器不会报错，只会静默忽略aria-label，调试时容易误判
哪些地方绝对不能加 aria-label？
加了不仅没用，还会让屏幕阅读器跳过关键信息，甚至触发可访问性检查工具警告。
立即学习“前端免费学习笔记（深入）”；
-
<h1>到<h6>：标题的可访问名称就是自身文本，aria-label会完全覆盖它 -
<img>：必须用alt属性，aria-label在这里行为不可靠，可能重复朗读或被忽略 - 已有可见文本的按钮，如
<button>导出 PDF</button>：加aria-label="导出"会导致“PDF”被跳过，且多语言更新时文案脱节 -
<input type="checkbox">等原生表单控件：应优先配<label for="xxx">，aria-label是最后手段 -
<svg>自身：默认不可聚焦、不可交互，aria-label写在<svg>上无效；必须写在外层可交互容器上，如<button aria-label="下载"><svg></svg></button>
调试和验证的关键点
别信 HTML 里写了属性就生效。真正起作用的是浏览器计算出的「可访问名称（Accessible Name）」，它受多种因素影响。
- 用 Chrome DevTools 的「Accessibility」面板，展开目标元素，看「Name Computation」一栏是否显示有效来源
- ID 引用失效时不会报错，只会静默为空——这是最常被漏掉的坑
- 键盘焦点流必须同步验证：加了
aria-label的按钮，Tab 能否进入？Enter/Space 是否触发？视觉焦点样式是否清晰？ - 自定义按钮（非
<button>）若用了role="button"，必须手动监听Space键，不只是Enter；否则键盘用户操作不一致
