order属性会改变屏幕阅读器朗读顺序和tab键焦点路径，chrome、firefox、safari均按视觉渲染顺序同步更新accessibility tree；仅当存在grid-row/column定位、display: contents或aria覆盖时，才退回html源序。
order属性会改变屏幕阅读器朗读顺序
它不是“应该影响”，而是浏览器实现规范时明确将 order 视为可访问性顺序依据之一。Chrome、Firefox 和 Safari 都按视觉渲染顺序同步调整 accessibility tree 中的节点顺序，所以屏幕阅读器和键盘 Tab 键都会跟随 order 排列——这不是 bug，是当前标准行为。
为什么“纯视觉重排”说法不准确
早年文档说 order “只改视觉”，但实际从 WCAG 2.1 和 ARIA 实践角度看，它已构成逻辑顺序变更：
- Tab 键焦点跳转路径与 order 一致
- 屏幕阅读器（如 NVDA、VoiceOver）默认按渲染顺序朗读，而非源码顺序
- DevTools 的 Accessibility 面板直接显示重排后的节点树，order: -1 的元素会出现在树顶
什么时候 order 不影响可访问性顺序
仅在以下情况，order 对可访问性“失效”（即回归源码顺序）：
- 元素设置了 grid-row 或 grid-column → 显式定位接管，order 被忽略，可访问性顺序也退回 HTML 源序
- 父容器用了 display: contents，且子元素未参与外层 Grid 布局 → order 不生效，自然也不影响可访问性
- 使用了 aria-flowto 或 aria-labelledby 等显式覆盖属性 → 可访问性顺序由 ARIA 控制，order 退居次要
真正可控的顺序方案是什么
如果你需要“视觉位置变、可访问性不变”，order 不是解法：
- 用 grid-column + grid-row 显式定位，它们不影响可访问性顺序（只改布局，不改 accessibility tree）
- 用 transform: translate() 移动元素 → 渲染位移但 DOM 和可访问性完全不动
- 在响应式场景中，优先通过媒体查询切换两套 HTML 结构（如 <main></main> 和 <aside></aside> 互换位置），再辅以 CSS 定位 —— 这样语义、焦点、朗读全部一致
- 若必须用 order，务必同步加 aria-order（虽非标准属性，但部分读屏器识别）或用 JS 动态调整 tabindex 补偿
实际项目里最容易被忽略的是：开发者测试时只看页面渲染，不按 Tab 键走一遍，也不开 VoiceOver 听一遍。一旦上线，键盘用户和视障用户立刻暴露问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
