aria-orientation 用于告知辅助技术控件的交互方向，仅对 role="slider"、"separator"、"scrollbar"、"treeitem" 等特定角色生效，且必须与角色、键盘行为、CSS布局三者严格一致，否则导致可访问性失效。
aria-orientation 不是“定义方向”的开关，而是告诉辅助技术“这个控件在交互上按什么方向响应”，它必须和 role、键盘行为、CSS布局三者对齐，缺一不可。
哪些元素加 aria-orientation 才有效
只对特定 role 生效：浏览器和屏幕阅读器只在 role="slider"、role="separator"、role="scrollbar"、role="treeitem"（部分实现）等语义角色上读取该属性。
-
<input type="range">不需要手动加 —— 浏览器自动根据 CSS 布局推断方向，并内置role="slider" -
<hr>或普通<div>加了aria-orientation也没用，因为没声明role，辅助技术直接忽略 - 自定义滑块（比如用
<div>+ 拖拽）必须同时满足：显式设role="slider"、aria-orientation、aria-valuenow等必要属性
水平 vs 垂直的键盘行为必须匹配
辅助技术会按 aria-orientation 去预期键盘操作：设成 "horizontal" 就该响应 ←/→，设成 "vertical" 就该响应 ↑/↓。如果代码里只改属性、不处理按键事件，屏幕阅读器会认为方向“说谎”——可能跳过该控件或报错。
- 水平滑块需监听
keydown中的ArrowLeft/ArrowRight，并调用preventDefault() - 垂直滑块对应
ArrowUp/ArrowDown，不能混用 - 仅靠 CSS
transform: rotate(90deg)让视觉变竖，但键盘仍走 ←/→，这和aria-orientation="vertical"冲突，反而降低可访问性
aria-orientation 和 CSS 布局必须一致
视觉方向、交互方向、ARIA 声明三者不一致时，辅助技术会困惑甚至静默失效。例如：
立即学习“前端免费学习笔记（深入）”；
- 一个
div设了aria-orientation="vertical"，但 CSS 是display: flex; flex-direction: row（水平排列），用户拖动时实际是横向移动 —— 这属于语义错误 - 分隔线用
<div role="separator" aria-orientation="vertical">，就必须确保它在页面中是真正垂直分割两个区域（比如侧边栏与主内容），且高度远大于宽度 - 用
writing-mode: vertical-rl实现文字竖排时，aria-orientation不起作用 —— 它和文本排版无关，只管交互控件
最容易被忽略的是键盘事件绑定是否真实响应了所声明的方向；很多团队加了 aria-orientation 就以为完事，结果屏幕阅读器用户按 ↑ 却没反应，反而比没加更误导。
