aria-orientation="vertical" 是为辅助技术明确可聚焦组件键盘操作逻辑的属性，仅对 tablist、toolbar 等具方向语义的 role 有效，需配合正确 role 使用，纯 CSS 布局不影响其行为。
aria-orientation="vertical" 是给谁用的？
这个属性不是用来“定义”导航栏方向的装饰性标签，而是为辅助技术（比如屏幕阅读器）明确当前可聚焦组件的键盘操作逻辑。它只对具有明确方向语义的交互控件有意义，比如 tablist、toolbar、menubar、slider 或 tree。普通 nav 或 ul 元素加了它，既不生效，还可能误导 AT 用户。
- 必须配合正确的
role使用，例如：<div role="tablist" aria-orientation="vertical"> - 对纯 CSS 布局（如 flex-direction: column）无影响，视觉方向由 CSS 控制，AT 行为由 ARIA 控制
- 如果用了
role="navigation"，不应加aria-orientation—— 这个 role 本身不承诺方向性交互逻辑
垂直 tab 列表怎么写才真正生效？
垂直选项卡（vertical tabs）是 aria-orientation="vertical" 的典型合法场景。关键在于：角色 + 方向 + 键盘行为一致。
- 使用
role="tablist"包裹所有tab，每个tab设role="tab"并关联tabpanel - 显式声明
aria-orientation="vertical"在tablist上 - 确保键盘导航符合垂直预期：↑/↓ 切换 tab，Enter 或 Space 激活，Home/End 跳首尾
- 示例片段：
<div role="tablist" aria-orientation="vertical"> <button role="tab" aria-selected="true" aria-controls="panel1">首页</button> <button role="tab" aria-selected="false" aria-controls="panel2">关于</button> </div>
加了 vertical 却被读成 horizontal？常见原因
屏幕阅读器仍按水平方式朗读或导航，大概率不是 ARIA 写错了，而是底层结构或状态没对齐：
-
aria-orientation值拼错，比如写成"verticle"或"vartical"（注意拼写） -
role缺失或错误：写了aria-orientation="vertical"但外层是<nav>或<ul>，没有对应 role -
aria-selected、aria-controls等必要属性缺失，导致 AT 降级为通用列表处理 - 浏览器或 AT 版本老旧，部分旧版 NVDA 或 JAWS 对某些 role+orientation 组合支持不完整（尤其在非标准容器中）
vertical 导航栏要不要加这个属性？
如果只是用 CSS 排成一列的 nav > ul > li > a，不要加 aria-orientation="vertical"。
立即学习“前端免费学习笔记（深入）”；
- 链接列表（
role="link"或隐式链接）没有方向性键盘约定，AT 默认线性遍历 - 加了反而可能触发 AT 的垂直 tab 模式逻辑，导致 ↑/↓ 键失效或行为异常
- 真正需要控制方向交互的，应重构为语义匹配的 widget：比如用
role="menu"+aria-orientation="vertical"，同时实现ArrowUp/ArrowDown处理
实际中最容易被忽略的，是把视觉样式和 ARIA 语义混为一谈 —— 人眼看到纵向排列，不代表 AT 就该按纵向 widget 解读。决定权不在布局，而在 role 和交互契约。
