必须结合ARIA属性、焦点管理和语义化结构提升无障碍体验；display: none虽隐藏视觉且屏蔽读屏，但表单控件仍会提交，应加disabled；visibility: hidden不屏蔽读屏，需配合aria-hidden="true"和tabindex="-1"等处理焦点与播报。
不能靠 visibility: hidden 或 display: none 单独提升无障碍体验；必须配合 aria-hidden、focus 管理和语义化结构才有效。
display: none 默认对屏幕阅读器“隐身”，但表单数据仍会提交
这是最常被忽略的矛盾点：display: none 的 <input> 元素在 DOM 中依然存在，用户看不见、读屏软件也默认跳过，但它仍会随表单一起提交——导致后端收到意料之外的空值或脏数据。
- 若需彻底移除可访问性树中的节点且不提交，用
display: none+aria-hidden="true"是冗余的，display: none本身已满足读屏屏蔽 - 但若该元素是表单控件，更稳妥的做法是加
disabled属性（同时禁用交互和提交） - 千万别只依赖
display: none来“隐藏”必填字段——它只是视觉消失，逻辑上仍参与表单验证流程
visibility: hidden 默认会被屏幕阅读器读出，必须手动屏蔽
visibility: hidden 不影响可访问性树，读屏软件照常解析内容。比如一个用 visibility: hidden 隐藏的错误提示，用户可能听到“用户名格式错误”，却看不到对应输入框在哪。
- 必须显式添加
aria-hidden="true"才能阻止读屏播报 - 若该元素内含可聚焦子项（如按钮），即使父级
visibility: hidden，Tab键仍能聚焦到它——需额外加tabindex="-1"或disabled - 注意继承陷阱：如果祖先链中某层用了
visibility: hidden，而你只给子元素加了aria-hidden="false"，读屏器仍可能跳过——aria-hidden不继承，但渲染可见性继承
真正影响无障碍的关键不是“怎么隐藏”，而是“要不要让焦点停留”
很多键盘导航问题根源不在 CSS，而在 focus 流控制。例如模态框关闭后，焦点没回到触发按钮，用户就卡在空白页。
立即学习“前端免费学习笔记（深入）”；
- 用
display: none隐藏模态框时，记得在 JS 中调用triggerButton.focus()把焦点手动归还 - 用
visibility: hidden隐藏遮罩层时，若里面有个“跳过引导”按钮设了visibility: visible，它必须可聚焦且有明确aria-label - 不要依赖
hiddenHTML 属性代替 CSS：它等价于display: none，但语义更强，更适合标记“暂不相关”的内容（如未激活的 tabpanel）
最易被忽略的是：CSS 隐藏方式本身不决定无障碍行为，它只影响视觉呈现；真正起作用的是 DOM 结构、ARIA 属性和 JS 焦点管理三者的组合。选 display: none 还是 visibility: hidden，首先要问的是“这个元素是否还该存在于用户的交互路径中”，而不是“它看起来有没有”。
