hidden与aria-hidden="true"不能混用，否则因语义冲突导致读屏跳过内容或状态不同步；hidden移除渲染树和可访问性树，aria-hidden仅隐藏辅助技术感知，二者机制矛盾。
hidden 属性和 aria-hidden="true" 一起用会出什么问题
两者语义完全冲突，浏览器和屏幕阅读器会陷入矛盾状态。比如一个按钮同时带 hidden 和 aria-hidden="true"：视觉上消失、DOM 中不可达（hidden 移除了渲染树）、但 ARIA 又声称“这个元素对辅助技术不可见”——而它本来就已经不可见了。部分读屏器会报错或跳过整个父容器。
更常见的是误写成 hidden="false"，其实只要属性存在，无论值是什么，都生效；正确做法是用 element.removeAttribute('hidden') 动态移除。
-
hidden是语义级隐藏：不占空间、不响应事件、不进可访问性树 -
aria-hidden="true"是可访问性树级隐藏：视觉还在，但读屏器忽略 - 混用等于“既不让看，又不让读，还占着 DOM 位置”，属于冗余且易触发兼容性问题
为什么 display: none 不等于“视觉隐藏”
它直接斩断渲染链，子元素再设 display: block 也无效。这对权限控制、模态框关闭等“区域本不该存在”的场景很合适，但若你只是想隐藏图标旁的说明文字供屏幕阅读器使用，就彻底切断了通路。
典型翻车点：表单里用 display: none 隐藏 <input name="token">，结果提交时字段被忽略——因为 hidden 属性和 display: none 都会让表单序列化跳过该控件。
立即学习“前端免费学习笔记（深入）”；
- 需要“视觉隐藏但参与提交”，得用
position: absolute; clip-path: inset(50%)类方案 - 用
visibility: hidden也不行：Tab 键仍能聚焦到空白处，键盘用户卡住 - 动画中频繁切换
display会触发重排，影响性能
sr-only 类怎么写才真正安全
网上流传的 .sr-only 片段常漏掉关键细节，导致某些 NVDA 版本或旧版 IE 下失效。W3C 推荐组合必须包含非零宽高、绝对定位、裁剪和白空间控制。
现代写法优先用 clip-path: inset(50%)，老浏览器回退到 clip: rect(0, 0, 0, 0)，并加 @supports 检测。
- 必须设
width: 1px; height: 1px，否则部分读屏器认为“无内容”直接跳过 - 避免只用
opacity: 0：它仍可聚焦、可点击，需配pointer-events: none和tabindex="-1" - 父容器若设
overflow: hidden，可能把绝对定位的隐藏文本裁掉，要检查层级
aria-label 和视觉隐藏文本能不能共存
能，但不能随便塞。比如在 <h3> 上加 aria-label，会覆盖其内部文本，破坏原生标题语义——读屏器不再读“联系我们”，而是读你写的 aria-label 值，哪怕两者内容一致，也增加维护负担。
真正需要的是“补充说明”，比如按钮图标旁加“仅限会员”提示，这时用视觉隐藏文本更合理；而纯图标按钮，直接用 aria-label 更轻量。
- 同时写
aria-label和视觉隐藏子元素，大概率导致重复播报 -
<label>内嵌视觉隐藏文本是安全的，因为label本身就是可访问容器 - 最难的不是 CSS 写对，而是每次加隐藏文本前问一句：这个信息对键盘用户、触控用户、读屏用户，是否都能以一致方式抵达？
