会，但只在特定情况下；当position: absolute/fixed使视觉顺序与DOM语义顺序不一致时，如“跳过导航”链接放末尾却视觉置顶，屏幕阅读器仍按源码顺序读取，导致功能失效。
定位元素会破坏阅读顺序吗
会，但只在特定情况下。当使用 position: absolute 或 position: fixed 将元素从文档流中移出，且未同步调整其在 DOM 中的位置时，屏幕阅读器通常仍按 HTML 源顺序读取，而视觉上它可能出现在页面任意位置——这就造成「视觉顺序 ≠ 语义顺序」。
例如一个跳转到主内容的“跳过导航”链接，如果用 position: absolute 移到左上角但保留在
- 关键判断点：检查该元素是否承担导航、操作或信息传达功能
- 安全做法：把
absolute元素尽量放在 DOM 中符合逻辑的位置（如“跳过链接”放开头） - 避免对
、、内部结构做脱离文档流的重排
z-index 和 focus 可达性冲突常见吗
非常常见。高 z-index 不等于高可访问性——如果一个模态框（position: fixed）的 tabindex 未设为 0 或 -1，且其父容器有 overflow: hidden 或 visibility: hidden，键盘用户可能根本无法聚焦其中控件。
更隐蔽的问题是：某些绝对定位元素因层级过高，遮挡了下方可聚焦元素，但 DOM 中它仍在下方，导致焦点“穿过”不可见区域，表现为按 Tab 键时焦点消失或跳步。
立即学习“前端免费学习笔记（深入）”；
- 必须确保模态框启用
inert属性（或手动tabindex="-1"+aria-hidden="true"处理背景） - 用浏览器的「Accessibility Inspector」查看焦点路径，不要只信视觉层级
-
z-index值本身不影响可访问性，但配合pointer-events: none或opacity: 0会直接让元素不可聚焦、不可读
transform 平移替代 position 是否更安全
是的，多数场景下更安全。因为 transform: translate() 不改变文档流，也不影响元素的语义位置和阅读顺序，屏幕阅读器仍按 DOM 顺序处理，键盘焦点也能自然抵达。
但要注意：仅用 不用等测试报告，三步现场查： 特别留意那些靠 最易被忽略的是：用 transform 移动一个原本不可聚焦的元素（如 tabindex="0" 并处理 Enter/Space 事件。
+ 正确 aria-expanded 状态）transform + will-change: transform 可能触发渲染层提升，在老旧 Android WebView 中引发焦点丢失，慎用于关键交互入口如何快速验证定位带来的可访问性风险
1. 关掉样式（浏览器 DevTools → ⚡️「Disable Styles」）
2. 按 Tab 键遍历焦点，观察是否跳过重要控件、是否进入不可见区域
3. 打开屏幕阅读器（NVDA / VoiceOver），从页面顶部线性朗读，确认关键信息出现时机合理
left: -9999px 实现的“隐藏但可读”技巧——现代 SR 对 clip-path、text-indent 等方式兼容不一，建议统一用 clip + position: absolute + white-space: nowrap 组合，并始终包裹在语义化标签内。position: relative 配合 top/left 微调布局时，若父容器有 overflow: hidden，可能裁剪掉焦点指示框（focus ring），让用户误以为焦点丢失——这时需要额外加 outline-offset 或改用 box-shadow 模拟焦点环。
