CSS reading-flow 怎么让 Grid 视觉顺序和 Tab 顺序一致：reading-order 与降级

响应式商品卡片最容易留下一个“看起来没问题”的键盘坑：桌面端用 CSS Grid 排成三列，窄屏再换成两列或一列，眼睛看到的顺序变了，Tab 键却还按 DOM 里的旧顺序跳。鼠标用户能顺着卡片流畅浏览，键盘用户和屏幕阅读器用户却可能先进入右侧卡片，再跳转回左侧区域。

优先修复顺序的方案还是调整 HTML 源顺序，让 DOM 本身表达出符合用户习惯的阅读逻辑。CSS reading-flow 适合处理确实需要让布局顺序和阅读、Tab 顺序同步的场景，但它目前仍是实验性能力，绝对不能当成替代合理语义结构的捷径。

先看清 Grid 顺序为什么会和 Tab 顺序分开

默认情况下，浏览器按 DOM 顺序解读内容，也会按这个顺序把焦点依次交给页面里的链接和按钮。CSS 的 order、grid-auto-flow 或响应式布局写法只改变元素的视觉摆放位置，不会自动重写底层的 DOM 顺序。

  A：入门套餐
  B：团队套餐
  C：企业套餐

如果桌面端采用从右到左的特殊视觉排布，或者移动端通过 order 把促销卡片直接移到最前面，用户肉眼看到的 A、B、C 可能变成 C、A、B，但 Tab 跳转顺序仍然是原生的 A、B、C。这个差异不是无关紧要的样式瑕疵，而是实实在在改变了键盘用户的完整操作路径。

用 reading-flow 处理 Grid 的行列阅读方向

针对网格布局，可以在容器上设置 reading-flow: grid-columns 或 reading-flow: grid-rows。前者按视觉上的列方向安排阅读顺序，后者按行方向安排阅读顺序。它们解决的是容器子项之间的阅读顺序问题，不会替你修复按钮名称、标题层级或链接目的地这类原生可访问性问题。

.product-grid {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 1rem;
  reading-flow: grid-rows;
}

@media (max-width: 700px) {
  .product-grid {
    grid-template-columns: 1fr;
  }
}

这段样式的核心作用不是“让 Tab 看起来顺眼”，而是让支持该属性的浏览器在网格排列动态变化后，仍按页面实际呈现的行方向处理所有卡片的跳转顺序。测试的时候要把鼠标移开，直接按 Tab 键操作，记录焦点环从哪个卡片跳到哪个卡片，完整走一遍流程。

什么时候需要 reading-order

reading-flow: source-order 本身仍然遵循 DOM 基础顺序，它的作用是开启对子项使用 reading-order 的能力。只有当一个容器里确实存在多个明确的视觉分组，且每组内部顺序需要单独明确指定时，才考虑使用这个组合。

.dashboard {
  display: grid;
  reading-flow: source-order;
}

.dashboard .primary {
  reading-order: 1;
}

.dashboard .secondary {
  reading-order: 2;
}

这里的数字不是给所有元素重新编号的万能排序器。它更像给子项划分不同的阅读组：先读 primary，再读 secondary。如果页面本来可以通过直接调整 DOM 顺序表达这个关系，就没必要额外增加这层 CSS 规则。

降级写法：让不支持的浏览器仍然可用

MDN 将 reading-flow 标为实验性能力，正式上线前要把它当成额外的增强层来处理。可以保留一个简单的能力检测，用于记录实验性样式是否生效，但不要在检测失败时用脚本强行重排焦点顺序。

const supportsReadingFlow = CSS.supports('reading-flow', 'grid-rows');
document.documentElement.classList.toggle(
  'has-reading-flow',
  supportsReadingFlow
);

真正可靠的降级方案是 HTML 源顺序本身：标题、说明、价格和按钮要按普通用户理解的正常顺序出现；不要用正整数 tabindex 重新编排整页顺序，也不要把不可见的重复链接塞进页面里。支持增强属性的浏览器可以获得更贴合视觉的跳转顺序，不支持的浏览器用户仍能正常完成浏览和购买全流程。

上线前用键盘完成一次验收

1. 缩放到桌面、平板和手机三个宽度，分别观察各场景下卡片的视觉顺序。
2. 从地址栏位置后按 Tab 键，确认焦点环不会跳过卡片内的标题链接或操作按钮。
3. 打开开发者工具禁用 reading-flow，确认页面仍按 DOM 顺序可以完成所有核心任务。
4. 用屏幕阅读器或浏览器自带朗读功能复查标题、价格和按钮名称，不能只检查焦点位置是否正确。

如果视觉顺序和业务逻辑顺序经常产生冲突，优先改 HTML 结构。CSS 属性可以补足布局带来的阅读顺序差异，却不应该替产品信息架构的不合理设计兜底。

常见问题

reading-flow 会改变元素在 DOM 里的位置吗？

不会。它只会影响支持该能力的浏览器如何处理子项的阅读与顺序，DOM 节点本身没有被移动。

reading-flow 和 tabindex 哪个更适合调整 Tab 顺序？

优先保持合理的 DOM 顺序，必要时使用 reading-flow；不要用一串连续的正整数 tabindex 维护复杂的全页面焦点路线。

reading-flow 在所有浏览器都能用吗？

不能把它视为普遍可用的兼容能力。它仍处于实验性阶段，发布前要查目标浏览器的兼容性列表，并验证不支持该属性时的原生 DOM 顺序是否可用。

reading-order 单独写为什么没有效果？

它需要放在配置了对应 reading-flow 的容器中使用。如果容器没有开启对应的阅读流，子项的 reading-order 不会单独改写页面顺序。

把顺序问题留在可验证的结构里

一个可维护的 Grid 页面，应该先让 HTML 表达内容关系，再让 CSS 表达空间关系，最后才用 reading-flow 处理确实存在的视觉与阅读顺序差异。上线验收时同时检查视觉、Tab 焦点和 DOM 降级效果，这比只在设计稿里确认卡片位置更接近真实用户的实际操作路径。