role="scrollbar" 是 ARIA 规范定义的语义角色，仅声明元素为滚动条控件，不提供任何功能；必须配套实现 aria-valuenow、键盘/鼠标事件、焦点管理及视图同步，且仅适用于完全自定义滚动条场景。
role="scrollbar" 是什么，能不能直接用
role="scrollbar" 是 ARIA 规范里定义的一个“角色”，用来告诉辅助技术（比如读屏软件）：这个元素是一个滚动条控件。但它不是让你随便加在某个 div 或 span 上就能变出滚动条的魔法属性。浏览器不会因为写了 role="scrollbar" 就自动渲染一个可拖动的滚动条，也不会绑定鼠标/键盘事件——它只负责“声明语义”，不负责“实现行为”。
真实场景中，你几乎不会手动创建一个 role="scrollbar" 元素。原生 <input type="range">、<textarea> 或容器自带的溢出滚动（overflow: auto）才是主流方案。ARIA 滚动条角色主要用于自研滚动组件（比如完全重写的虚拟滚动条），且必须配套实现全部交互逻辑。
什么时候真得用 role="scrollbar"
只有当你在写一个完全自定义的、非原生的滚动条 UI 组件时，才可能需要它。例如：用 canvas 渲染的滚动条、为 WebGL 应用做的 overlay 滚动控件、或某些受限环境（如 Webview 内核禁用原生滚动）下被迫手写滚动逻辑。
- 必须同时提供
aria-valuenow、aria-valuemin、aria-valuemax和aria-orientation - 必须监听
keydown（方向键、Home/End/PageUp/PageDown）、鼠标拖拽、点击轨道等事件并手动更新值 - 必须用
tabindex="0"让它可聚焦，并处理focus/blur状态样式 - 必须同步更新视图区域的滚动位置（比如调用
element.scrollTop或transform位移）
常见错误：加了 role="scrollbar" 却没配 aria-* 属性
只写 role="scrollbar" 而不带 aria-valuenow 等属性，会导致读屏软件报错或静默忽略。典型错误现象：
立即学习“前端免费学习笔记（深入）”；
• NVDA 或 VoiceOver 读作 “scrollbar” 后立刻中断，不读当前值
• Chrome 的 Accessibility DevTools 显示 “Invalid scrollbar: missing required attributes”
• 自动化测试工具（如 axe）直接标为严重可访问性问题
正确写法示例（水平滚动条）：
<div role="scrollbar"
aria-orientation="horizontal"
aria-valuenow="42"
aria-valuemin="0"
aria-valuemax="100"
tabindex="0">
<div class="thumb" style="width: 20px; left: 42%;"></div>
</div>替代方案：优先用原生滚动 + CSS 自定义
99% 的滚动需求，应该避开 role="scrollbar"，改用更可靠的方式：
- 对容器设
overflow-y: auto，再用 CSS 伪元素定制外观（::-webkit-scrollbar系列） - 用
scrollbar-width（Firefox）和scrollbar-color控制宽窄与颜色 - 需要精细控制时，用
Element.scrollTo()或scrollIntoView()配合事件监听 - 若要隐藏原生滚动条但保留滚动能力，用
overflow: hidden+ 手动scrollTop更新，此时也不需要role="scrollbar"—— 因为用户操作的是容器本身，不是“滚动条控件”
真正难的不是加 ARIA 属性，而是让自定义滚动条在键盘、触屏、读屏、缩放、高对比度模式下全都一致工作。多数项目卡在这一步就退回用了原生方案。
