CSS reading-flow 怎样让卡片的键盘顺序跟随视觉布局

如果卡片在 CSS Grid 或 Flex 中为了响应式布局改变了视觉位置，默认的 Tab 顺序仍然来自 DOM 源码顺序，用户就可能看到焦点从右下角跳回左上角。reading-flow 可以在支持它的浏览器中，让块、Flex 或 Grid 容器的阅读与顺序导航贴近视觉排列；但它是实验性能力，源码顺序仍要先设计成可读、可操作的降级方案。

官方资料：https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/reading-flow

最稳妥的做法是：先用 HTML 排出合理的默认顺序，再在明确的 Grid/Flex 场景使用 reading-flow，只有少量例外才用 reading-order，不要用正值 tabindex 硬改焦点路线。

先让 DOM 源码顺序本身成立

reading-flow 不能替代语义结构。下面的卡片先按“概览、安装、配置、排错”排列，哪怕浏览器忽略后续 CSS，读者仍能按这个顺序阅读和操作：

部署指南
  
概览
安装
配置
排错

这里最重要的不是卡片的颜色或间距，而是内容顺序。不要为了让桌面端“看起来像设计稿”而先把 HTML 写成一套不可读的顺序，再用 CSS 反复搬运焦点。

Grid 卡片怎样按视觉行顺序导航

对于多列卡片，reading-flow: grid-rows 表示按网格行读取，reading-flow: grid-columns 表示按列读取。选择哪一个，取决于用户扫视页面时的主要方向。大多数横向卡片列表适合先完成第一行再进入第二行：

.cards {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 1rem;
  /* 让顺序导航按视觉上的第一行、第二行依次前进。 */
  reading-flow: grid-rows;
}

.card {
  min-block-size: 8rem;
  /* 让链接占满卡片，焦点状态更容易被看见。 */
  display: grid;
  align-content: start;
}

.card a:focus-visible {
  /* 用清晰轮廓提示当前 Tab 焦点，不改变阅读顺序。 */
  outline: 3px solid #2457d6;
  outline-offset: 4px;
}

例如四张卡片的 DOM 顺序是 A、B、C、D，双列布局的视觉顺序也是 A、B、C、D 时，grid-rows 不会带来额外变化；它的价值在于布局规则改变后，顺序导航仍能跟着渲染出来的行走。规范把这个容器称为 reading flow container。

什么时候使用 grid-columns 或 flex-visual

如果界面是纵向目录、时间轴式列布局或用户习惯逐列扫描，可以选择 grid-columns。对于 Flex 容器，常见值是 flex-visual 和 flex-flow：前者更接近最终视觉位置，后者更接近 Flex 流向。两者不是“哪个更高级”，而是回答不同问题。

尤其要注意 row-reverse、order 和不同 writing mode 叠加后的结果。不要只凭 CSS 声明猜 Tab 顺序，应该在键盘上从第一个可聚焦元素走一遍。

少量例外用 reading-order 分组

有时卡片视觉上按网格排列，但“推荐”卡片需要先被访问，或者最后一张卡片要放到整个组件末尾。这时可以让父容器进入 source-order，再用子项的 reading-order 设置序号组：

.cards {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  /* 开启子项 reading-order 的序号分组能力。 */
  reading-flow: source-order;
}

.card--featured {
  /* 负数分组会在默认的 0 组之前被访问。 */
  reading-order: -1;
}

.card--more {
  /* 正数分组会在默认的 0 组之后被访问。 */
  reading-order: 1;
}

reading-order 只改变阅读与顺序导航，不改变视觉位置。相同序号组中的兄弟元素仍按父容器的 reading flow 规则排列，所以不要给每张卡片都写一串人为编号；只标记确实有业务优先级的例外。

不要用正 tabindex 修补顺序

正值 tabindex 会把焦点路线变成维护成本很高的人工列表。MDN 对 reading flow 的说明也指出，在 reading flow 容器中，正值 tabindex 的顺序修改会被这些属性覆盖；更实际的策略是保留 tabindex="0" 或原生可聚焦元素，让 CSS 处理布局和顺序关系。

配置

如果一个元素本来不需要交互，不要为了让它进入 Tab 顺序而随意添加 tabindex="0"。先确认它是否应该是链接、按钮或其他语义控件。

用 supports 保留浏览器降级

reading-flow 与 reading-order 目前属于有限支持的实验性能力。可以用 @supports 把增强样式包起来，但不要把核心信息只放在增强路径里：

.cards {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  /* 默认状态依赖合理 DOM 顺序，保证基础可用。 */
}

@supports (reading-flow: grid-rows) {
  .cards {
    /* 支持时再让导航明确跟随视觉行。 */
    reading-flow: grid-rows;
  }
}

@supports (reading-order: 1) {
  .card--featured {
    /* 只对确有优先级的卡片启用顺序分组。 */
    reading-order: -1;
  }
}

这样，不支持属性的浏览器仍会按 DOM 顺序呈现内容；支持属性的浏览器才获得与视觉布局更一致的顺序导航。增强样式上线前，还应检查小屏媒体查询是否改变了列数、方向或卡片顺序。

一套可复用的检查清单

1. 看源码：禁用 CSS 增强后，标题、链接和操作是否仍是合理顺序。
2. 走 Tab：从组件前一个可聚焦元素开始，记录焦点是否按视觉扫视方向前进。
3. 看例外：只有确有优先级的卡片使用 reading-order，不为每项制造编号。
4. 看降级：检查不支持 reading-flow 的浏览器和小屏布局，确认信息没有消失。
5. 看语义：链接、按钮、标题和区域标签保持正确 HTML 语义，不靠 CSS 顺序掩盖结构问题。

一句话总结：reading-flow 负责让容器的阅读与顺序导航贴近 Grid/Flex 布局，reading-order 负责少量子项的分组调整；真正的兼容性和可访问性基础，仍然是正确的 DOM 顺序和原生交互语义。

常见问题

reading-flow 会改变卡片的视觉位置吗？

它主要修改阅读和顺序导航关系，不是替代 Grid 或 Flex 布局的定位属性。视觉布局仍由原有的 Grid、Flex、order 等规则决定。

reading-order 能代替 DOM 重排吗？

不能把它当作普遍的 DOM 重排工具。它适合少量例外；如果整个页面的内容逻辑都依赖视觉顺序，应该先重写源码结构。

为什么支持 reading-flow 仍要测试 Tab？

真实组件可能同时有媒体查询、嵌套容器、非链接控件和方向规则。属性的目标很明确，但最终顺序仍应通过键盘路径与读屏体验确认。