order仅改变视觉顺序，不影响DOM、Tab焦点、屏幕阅读器朗读及SEO；生效需父容器设display:grid且子元素未被显式定位（如grid-row/area），否则无效。
不会影响——order、grid-area、grid-row 等纯 CSS 手段改变的只是视觉顺序，屏幕阅读器、Tab 键焦点流、SEO 抓取全部按 HTML 原始 DOM 顺序执行。
为什么无障碍完全不受影响
CSS Grid 的视觉重排（比如用 order 或 grid-template-areas）发生在渲染层，不触碰文档树。浏览器的可访问性 API 读取的是 DOM 结构本身，不是样式计算后的结果。
- 用户按 Tab 键时，焦点仍从
<header></header>→<nav></nav>→<main></main>→<aside></aside>依次移动，哪怕你用order: -1把<aside></aside>放到了最前面 - 屏幕阅读器朗读顺序和源码一致，不会因为
grid-area: "sidebar"被塞进顶部就提前读它 - 搜索引擎爬虫只解析 HTML，CSS 里怎么挪位置，对索引毫无作用
哪些操作会真正破坏无障碍
真正危险的不是 CSS 排序，而是误以为它能“解决语义问题”而跳过结构优化。
- 把
<aside></aside>写在<main></main>前面，再靠order: 1让它视觉上后置——结果屏幕阅读器先读侧边栏，用户一头雾水 - 在媒体查询里疯狂切换
order值（比如 desktoporder: 2→ mobileorder: -5），导致键盘用户缩放后焦点突然跳到页面中间 - 用
display: contents隐藏容器但没补role或aria-labelledby，让子元素失去语义上下文
怎么验证你的 Grid 排序没伤无障碍
别只看页面长什么样，关掉 CSS 后检查三件事：
立即学习“前端免费学习笔记（深入）”；
- 打开开发者工具的 Accessibility 面板，确认 accessibility tree 的节点顺序和 HTML 源码一致
- 用键盘 Tab 键从头走到尾，记录焦点停驻点是否符合用户预期逻辑流
- 用 VoiceOver 或 NVDA 朗读整页，听它是否按你希望的信息优先级来组织内容
真正需要换序时，优先改 HTML：移动端把 <main></main> 放最前，桌面端再用 CSS 调视觉位置。CSS 是画布，DOM 才是底稿——这点容易被忽略，但决定无障碍成败。
