HTML hidden属性与ARIA状态：别让代码冲突，读屏用户易“迷失”

先说结论：hidden 和 ARIA 状态属性（例如 aria-hidden、aria-expanded）绝不能混合使用。不少人误以为这是“双重保障”，但实际上，二者极易“冲突”——导致屏幕阅读器要么直接跳过内容不朗读，要么播报的状态与界面实际展示不一致。真正能够确保读屏软件正确朗读的，是扎实的语义结构搭配实时同步更新的 ARIA 状态。hidden 本身对读屏而言几乎没有意义，甚至可能把可访问性树变得“残缺”。

为何说 hidden 对屏幕阅读器几乎无效？

hidden 属性本质上是一个全局布尔开关。一旦生效，元素会直接从渲染树中“消失”——视觉上不可见，也不占据页面空间。同时，它还会将该元素从可访问性树中一并移除。问题就在于：它“消失”得毫无征兆，不提供任何状态上下文，读屏软件自然无法播报任何信息，更别提“暂时隐藏但即将显示”这类动态意图了。

• 一个添加了 hidden 的

  ，读屏器根本感知不到它的存在，连“已隐藏”这样的提示都不会出现。

• 它完全无法替代 aria-expanded="false" 这类具有明确语义的状态属性。
• 即便与 aria-live 配合使用（例如先隐藏再显示），如果通过 innerHTML 整体替换DOM，读屏器大概率会错过这个动态变化，用户完全无感知。

aria-hidden="true" 与 hidden：切勿让它们同时出现

这两个属性的作用机制相互冲突。hidden 是直接将整个节点从文档流和可访问性树中移除；而 aria-hidden="true" 仅仅是让辅助技术“忽略”该节点，节点本身依然存在于DOM中，JavaScript 照样可以操作它。

如果同时设置，浏览器之间的行为会变得非常微妙。有的读屏器可能直接忽略 aria-hidden，只认 hidden；另一些则可能因属性冲突而产生难以预料的后果。使用自动化工具（如 axe）检测时，会直接报错“conflicting visibility attributes”。

• 错误用法：
• 正确的场景选择：
  • 如果目标是“视觉上隐藏，读屏也跳过”，仅使用 hidden 即可。但要注意，这相当于彻底“废弃”该元素，不适合像模态框背景遮罩这类仍需保留部分交互逻辑的场景。
  • 如果目标是“视觉可见，但读屏忽略”，则只能使用 aria-hidden="true"，并且必须确保该元素内没有可聚焦的控件（如按钮、输入框），否则用户会碰到一个“摸得着但看不见”的交互陷阱。

真正决定读屏朗读质量的，是 ARIA 状态的实时同步

读屏能否正确播报，核心在于 ARIA 状态属性是否与界面上的UI实际情况“保持一致”，而非依赖“藏起来再露出来”这类小技巧。举个例子，一个下拉菜单展开还是收起，关键不在于 hidden 这个开关，而在于 aria-expanded 的值是否在菜单展开或关闭的瞬间就完成更新；aria-activedescendant 是否精确指向当前高亮的选项；焦点是否被正确落在可操作区域上。

• aria-expanded="true" 必须在视觉展开后立即设置为 true，不能等到动画播完才更新。
• 模态框弹出时，应设置 aria-modal="true"、role="dialog"，以及 aria-labelledby 来指明弹窗标题，而不是随意给背景遮罩添加 hidden 了事。
• 对于动态加载的列表项，正确做法是使用 aria-live="polite" 区域包裹住新增内容，而不是反复控制父容器的 hidden 属性。

焦点管理：一个比属性本身更常被忽视的“雷区”

即便 ARIA 状态全部写得天衣无缝，如果键盘焦点没有锁定或跳转顺序混乱，读屏用户依然会像掉进迷宫般找不到方向。这个问题比属性本身更关键，却也更容易被忽略。

• 模态框打开后，必须用 focus() 方法主动将焦点“送入”第一个可聚焦元素（如标题或第一个输入框）。
• 关闭模态框时，焦点需要乖乖回到触发其打开的按钮上，否则用户按 Tab 键，可能直接掉到页面底部，或陷入空白区域。
• 千万不要依赖 CSS display: none 或 hidden 来“管理”焦点路径。这些属性只是让元素不可见，但并不会阻止键盘导航。结果就是，用户按 Tab 键会“摸”到一个看不见的控件，卡在空白处不知所措。

说到底，可访问性的复杂之处从来不在属性怎么写，而在于状态更新的时机、焦点流转的路径，以及DOM的更新方式是否与读屏器的预期节奏合拍。ARIA 不是一张随便贴贴的标签，而是一份需要实时履行的契约——写下了就必须兑现。