aria-flowto仅在当前dom树内生效，不触发页面跳转；目标元素须存在、id唯一、未被aria-hidden掩盖，且需tabindex="-1"或"0"方可被屏幕阅读器停驻。
aria-flowto 不能跨页面或跨 DOM 树跳转
aria-flowto 只在当前文档内生效，且仅对同一 DOM 树中的元素起作用。它不会触发页面跳转、不改变 URL、也不等价于 <a href></a>。如果你试图用它“跳到另一个 HTML 文件”，浏览器会静默忽略——因为目标元素根本不存在于当前 DOM 中。
常见错误现象：aria-flowto="header" 指向一个 ID 为 header 的元素，但该元素被 display: none 或 visibility: hidden 隐藏，或尚未渲染（比如动态加载的 React 组件），此时屏幕阅读器（如 NVDA、VoiceOver）通常跳过该流向，不报错也不提示。
- 必须确保目标元素存在、有有效 ID、且未被
aria-hidden="true"掩盖 - 多个源元素可指向同一目标，但一个元素只能有一个
aria-flowto值（不支持逗号分隔列表） - 若目标元素有
tabindex="-1"，它可被流式导航抵达；若为tabindex="-1"且无焦点样式，用户可能“到达却不可见”
与 tabindex 和 aria-labelledby 的协作关系
aria-flowto 不影响键盘 Tab 顺序，它只影响屏幕阅读器的“虚拟光标”流向。也就是说：按 Tab 键仍按 DOM 顺序走，而按 Ctrl+Alt+→（NVDA）或 VO+→（VoiceOver）才会触发 aria-flowto 路径。
典型使用场景：仪表盘中，主内容区之后逻辑上应跳转到右侧的实时数据卡片，而非下方的页脚；或表单中，验证失败后直接流向第一个错误字段。
- 必须配合
tabindex="0"或tabindex="-1"让目标元素可聚焦，否则部分读屏器无法停驻 -
aria-labelledby可用于增强目标元素的朗读说明（例如<div id="live-stats" aria-labelledby="stats-label">），但不替代 <code>aria-flowto的导航功能 - 避免和
aria-owns混用：后者用于逻辑归属，前者用于阅读流向，语义不同，强行组合易导致读屏器行为冲突
实际可用的最小可行示例
下面是一个能被 NVDA 2023.4+ 和 VoiceOver macOS Sonoma 正确识别的片段：
<main aria-flowto="dashboard-summary"><h1>销售总览</h1> <p>今日成交额：¥248,900</p> </main><p><aside id="dashboard-summary" tabindex="-1"><h2>关键指标摘要</h2> <p>转化率 ↑12%，跳出率 ↓7%</p> </aside></p>
注意：tabindex="-1" 是关键——它让 dashboard-summary 可被流式导航选中，但不进入自然 Tab 序列；若去掉，多数读屏器会跳过该节点。
- 不要写
aria-flowto="#dashboard-summary"（带 # 是 CSS 选择器语法，ARIA 属性值只需 ID 名） - 目标元素 ID 必须全局唯一；重复 ID 会导致流向随机命中其中一个，行为不可预测
- Chrome + ChromeVox 对
aria-flowto支持极弱，基本不响应；务必在真实读屏器下测试
比 aria-flowto 更可靠的实际替代方案
现实中，aria-flowto 兼容性差、调试困难、且多数用户并不知晓其存在。更稳妥的做法是：用显式跳转控件 + 无障碍焦点管理。
- 提供“跳至摘要”按钮，点击后执行
document.getElementById('dashboard-summary').focus() - 用
aria-live="polite"区域播报跳转成功（例如“已跳转至关键指标摘要”） - 对复杂视图（如多步骤表单），优先用
aria-current="step"+ 隐藏的<nav aria-label="步骤导航"></nav>提供结构化路径 - 若必须用流式导航，建议仅作为辅助手段，并始终保留可见的、键盘可操作的跳转链接
真正容易被忽略的一点：即使你完整实现了 aria-flowto，如果目标区域没有足够的上下文说明（比如没用 aria-label 或 aria-describedby 补充目的），屏幕阅读器用户抵达后仍可能困惑“这是什么？为什么到这里？”——流向只是路径，不是解释。
