aria-hidden="true"仅屏蔽屏幕阅读器读取，不隐藏视觉内容；只适用于纯装饰性图标或临时移出可访问流的dom片段，且须配合焦点管理；误用于交互容器将导致“看得见却听不到”或“听得到却点不了”。
aria-hidden 不是视觉隐藏开关，它只告诉屏幕阅读器“别读这个”，但元素仍可见、可点击、可聚焦——用错位置，用户看得见却听不到，或听得到却点不了。
什么时候该加 aria-hidden="true"？
只用于两类明确场景：
- 纯装饰性内容：比如按钮旁的图标
<i class="icon-trash"></i>，且旁边已有“删除”文本 - 临时移出可访问流的 DOM 片段：如模态框打开时，将背景区域设为
aria-hidden="true"，但必须配合焦点捕获和inert或tabindex="-1"防止键盘逃逸
常见误用：<div aria-hidden="true"><button>确认</button></div>——按钮仍能 tab 进去，但读屏完全跳过，状态断裂。
aria-hidden="true" 为什么不能套在父容器上？
它具有递归性：父元素设了，所有子元素默认不可访问，且子元素显式写 aria-hidden="false" 也无效（ARIA 规范明确禁止覆盖）。
- 错误示例：
<nav aria-hidden="true"><button>首页</button></nav>→ 整个导航对读屏消失 - 正确做法：若需隐藏导航，优先用
display: none；若仅屏蔽语义，应单独标记每个装饰图标，而非包裹容器 - 动态切换时，JS 必须同步更新属性值，不能只改 CSS
visibility或opacity
和 display: none、visibility: hidden 的关键区别
三者行为完全不同，混用会破坏可访问性一致性：
-
display: none：从渲染树和可访问树中彻底移除，屏幕阅读器看不见也读不到，推荐用于“真隐藏” -
visibility: hidden：保留在渲染树中（占位），但不渲染；可访问树中仍存在 → 屏幕阅读器可能读到，但用户看不到，极易造成困惑 -
aria-hidden="true"：保留在 DOM 和渲染树中，视觉正常，仅从可访问树中剔除 → 适合“看得见但不该读”的装饰
特别注意：<input>、<button></button> 等可聚焦元素加 aria-hidden="true" 后仍能获得键盘焦点，必须额外加 tabindex="-1" 或 disabled 才安全。
骨架屏、模态框、动态菜单里的典型陷阱
这些高频场景最容易踩坑：
- 骨架屏容器加
aria-hidden="true"→ 真实内容加载后，NVDA + Firefox 可能缓存该状态，导致新内容不播报 - 模态框打开时只设
role="dialog"，没配aria-modal="true"和aria-labelledby→ 读屏仍在读背景 - 移动端菜单按钮写
aria-expanded="active"（变量名），而非"true"/"false"字符串 → 属性非法，状态无法识别
真正关键的不是加不加，而是加在哪、何时切、是否同步焦点——可访问性断裂往往发生在状态切换的毫秒之间，而不是初始渲染那一刻。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
