aria-hidden="true" 不是隐藏开关而是辅助技术过滤器，仅当内容对读屏无意义时使用，严禁用于可交互元素；它不替代 display: none 或 hidden 属性，且需配合焦点管理与状态同步。
aria-hidden="true" 不能防止屏幕阅读器读取“隐藏内容”，它只屏蔽“已存在但无需播报”的内容
很多人以为加了 aria-hidden="true 就能让屏幕阅读器“看不见”某段内容，其实不是——它不改变元素是否“被隐藏”，只决定“是否向辅助技术暴露”。如果元素本身是 display: none 或带 hidden 属性，它已经从可访问性树中彻底消失，aria-hidden 根本没机会生效；反过来，如果元素视觉上明明可见，却硬加 aria-hidden="true"，屏幕阅读器会跳过，但键盘用户仍能 Tab 进去、点击触发行为，造成语义断裂。
常见错误现象包括：
-
<button aria-hidden="true">删除</button>：按钮照常聚焦、可按 Enter，但读屏完全静音 - 模态框开启后，背景区域没移除
aria-hidden="true"，关闭后读屏继续跳过本该恢复的内容 - 父容器设了
aria-hidden="true"，子节点里有<input>却没显式加aria-hidden="false"，导致表单控件不可读
真正该用 aria-hidden="true" 的三个典型场景
它不是“隐藏开关”，而是“辅助技术过滤器”，只在明确知道“这段内容对读屏无意义”时才启用：
- 纯装饰性图标：
<svg aria-hidden="true"><use href="#icon-trash"></use></svg>（前提是旁边有“删除”文字） - 轮播指示器容器：
<div class="carousel-dots" aria-hidden="true">…</div>（仅视觉提示，无操作语义） - 模态框激活时的背景遮罩层：
<div class="modal-backdrop" aria-hidden="true"></div>（防止读屏误读被盖住的页面主干内容）
关键约束：不能加在任何可聚焦、可交互的元素上（如 <button></button>、<a></a>、<input>），也不能加在包含这类子元素的容器上，除非你手动为每个子控件补 aria-hidden="false"。
为什么 button 内嵌图标要单独处理 aria-hidden
原生 <button></button> 会自动把子文本作为其可访问名称（accessible name）。但如果内部混入非语义节点，比如：<button><span class="icon"></span>提交</button>，部分读屏器（如 NVDA + Firefox）会把 <span></span> 当作独立文本节点读出，导致“图标 提交”或重复播报。
正确做法是：
- 给装饰性子元素明确加
aria-hidden="true"：<span class="icon" aria-hidden="true"></span> - 优先用
<svg focusable="false"></svg>替代<span></span>，避免被当作文本节点解析 - 确保按钮内**唯一非
aria-hidden的文本节点就是可访问名称来源**，不要同时用aria-label和可见文字
动态切换 aria-hidden 时最容易漏掉的两件事
用 JavaScript 控制 aria-hidden 时，光改属性远远不够。容易忽略的关键点：
- 焦点管理：模态框开启并给主内容加
aria-hidden="true"后，必须把焦点移到模态框内部首个可聚焦元素；关闭时不仅要移除aria-hidden，还要把焦点切回触发按钮或原位置 - 状态同步：若背景层和模态框内容共用一个父容器，不要只靠
aria-hidden切换，应配合inert属性（现代浏览器支持）或手动禁用所有子控件的tabindex和pointer-events
最危险的遗漏是：关闭模态框后忘记移除背景层的 aria-hidden="true"。此时读屏器仍跳过整个页面主体，用户无法导航，且无任何错误提示——这种“静默失效”最难排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
