aria-hidden="true"只该用在视觉存在但对辅助技术完全无意义的纯装饰性元素上；它仅屏蔽读屏器，不改变样式、DOM或事件，误用于可聚焦元素或容器会导致功能丢失和语义断裂。
直接说结论：aria-hidden="true" 只该用在「视觉上存在、但对辅助技术完全无意义」的元素上，加错位置会让屏幕阅读器用户彻底丢失功能，比不加更危险。
哪些元素能安全加 aria-hidden="true
它只屏蔽辅助技术（如读屏器），不改变视觉样式，也不影响 DOM 或事件响应。真正适合它的场景非常有限：
- 纯装饰性图标，且旁边已有明确文本说明（比如
<button>删除</button>里的垃圾桶<i class="icon-trash"></i>） - 轮播图的指示点容器（
<ol class="carousel-indicators">），当已有语音提示或标题说明当前页时 - 加载中动画里的冗余文字（如“加载中…”），而同一区域已用
aria-live同步播报状态 - SVG 内部仅用于描边/填充的
<path>，外层<svg>已设role="presentation"
关键判断标准：删掉这个元素，对屏幕阅读器用户理解页面结构和操作是否毫无影响？如果是，才考虑加。
哪些地方绝不能加 aria-hidden="true
常见误用不是“没加”，而是“加在了不该加的位置”，导致语义断裂：
立即学习“前端免费学习笔记（深入）”；
- 可聚焦元素本身（
<button>、<a>、带tabindex="0"的<div>）——它仍能获得焦点，但没朗读名，用户卡住却不知为何 - 折叠菜单的父容器（如
<nav aria-hidden="true">），但子项按钮仍可 tab 进入 → 状态不一致 - 模态框遮罩层（
<div class="modal-backdrop" aria-hidden="true">），却不锁键盘焦点 → 焦点逃逸到背后内容 - 整个
<main>或<article>—— 直接让整块主内容对读屏器不可见，且无替代入口
特别注意：aria-hidden="true" 具有继承性：父元素设了，所有子元素默认被屏蔽，子元素写 aria-hidden="false" 完全无效。
aria-hidden="true" 和 display: none、hidden 的区别
三者目标不同，不能混用或互相替代：
-
display: none：从渲染树和可访问树中完全移除，元素不可见、不可聚焦、不占空间、不触发事件 —— 适合真隐藏（如未激活的 tab 面板） -
hidden属性：HTML5 原生布尔属性，语义明确，效果等同display: none，但不依赖 CSS，即使样式加载失败也生效（IE9- 不支持） -
aria-hidden="true"：仅从可访问树中剔除，元素仍在 DOM 中、可被 CSS 控制、可能响应点击、仍占布局空间 —— 仅用于“看得见但不该读”
错误组合示例：<div hidden aria-hidden="true"> —— hidden 已让它彻底消失，aria-hidden 冗余；<button aria-hidden="true">提交</button> —— 按钮还能点，但读屏器完全不知道它是啥。
动态显示/隐藏时必须同步处理的三件事
JS 控制显隐不只是改 style.display 或切 class，否则读屏器会停留在旧状态：
- 显隐切换时，必须同步更新
aria-hidden值（true/false），不能只靠 CSS - 模态框打开后，用
element.focus()把键盘焦点移到首个可聚焦子元素（如关闭按钮），并确保背景内容不可聚焦（可用inert属性或手动tabindex="-1"） - 折叠面板展开时，优先用原生
<details><summary>，它自带aria-expanded、焦点管理、Space/Enter 支持，无需手写逻辑
最容易被忽略的是：aria-hidden 是静态标记，不会随 DOM 变化自动更新。你 JS 显示了一个区域，却忘了把它的 aria-hidden="true" 改成 false，读屏器就永远读不到新内容 —— 这种 bug 在测试中极难发现，但对真实用户是致命的。
