hidden与aria状态（如aria-hidden、aria-expanded）不能混用，否则易致读屏跳过内容或状态不同步；真正起作用的是语义结构加同步更新的aria状态，hidden本身移除可访问性树，不提供语义上下文。
直接说结论：hidden 和 ARIA 状态（如 aria-hidden、aria-expanded）不能混用去“保障读屏正确读数”，反而大概率导致读屏跳过内容或状态不同步。真正起作用的是语义结构 + 同步更新的 ARIA 状态，hidden 本身对读屏无意义，且会破坏可访问性树。
为什么hidden对屏幕阅读器几乎没用
hidden 是 HTML 全局布尔属性，它会让元素**从渲染树中移除**（视觉不可见、不占空间），同时也会从可访问性树中移除——但问题在于：它不提供任何状态上下文，也不触发读屏播报，更无法表达“暂时隐藏但即将出现”这类意图。
- 加了
hidden的<div>，读屏器根本“看不见”，连“已隐藏”都不会报 <li>它不能替代 <code>aria-expanded="false"这类有明确语义的状态属性 - 若和
aria-live配合使用（比如先hidden再显示），DOM 插入方式不当（如用innerHTML替换）会导致读屏完全错过变化 - 错误写法：
<div hidden aria-hidden="true">… → axe 工具直接报错“conflicting visibility attributes” <li>如果目标是“视觉隐藏 + 读屏也跳过”，只用 <code>hidden就够了（但注意：这等于彻底移除，不适合模态框背景遮罩等需保留交互的场景） - 如果目标是“视觉可见但读屏忽略”，只能用
aria-hidden="true"，且必须确保子元素没有可聚焦控件 -
aria-expanded="true"必须在视觉展开后立即设为true，不能滞后于动画结束 - 模态框打开时，应设
aria-modal="true"+role="dialog"+aria-labelledby，而不是给背景加hidden - 动态加载列表，用
aria-live="polite"区域包裹新增项，而非控制父容器的hidden属性 - 模态框打开后，必须用
focus()主动把焦点移到第一个可聚焦元素（如标题或首输入框） - 关闭模态框时，焦点要回到触发它的按钮，否则 Tab 键会落到页面底部或丢失
- 不要依赖 CSS
display: none或hidden来“管理”焦点路径——它们不阻止键盘导航，只是让元素不可见，用户 tab 过去会卡在空白处
aria-hidden="true" 和 hidden 别一起写
两者作用机制冲突：hidden 移除整个节点；aria-hidden="true" 只让辅助技术忽略该节点，但节点仍在 DOM 中、仍可被 JS 操作。同时写，浏览器行为不一致，部分读屏器可能忽略 aria-hidden，只按 hidden 处理；另一些则因属性冲突产生未定义行为。
真正影响读屏读数的是 ARIA 状态同步
读屏是否正确播报，取决于状态属性是否与 UI 实际一致，而不是靠“藏起来再露出来”。比如下拉菜单展开与否，关键不是 hidden 开关，而是 aria-expanded 值是否实时更新、aria-activedescendant 是否指向当前高亮项、焦点是否落在可操作区域。
容易被忽略的焦点管理问题
即使 ARIA 状态全对，如果键盘焦点没锁住或跳转错乱，读屏用户依然会迷失。这点比属性本身更关键，却常被跳过。
复杂点从来不在属性怎么写，而在状态更新时机、焦点流转路径、以及 DOM 更新方式是否与读屏器预期一致。ARIA 不是贴纸，是契约；写了就得实时履约。
