role="toolbar" 仅标识一组相关操作控件容器，需配合 aria-label/aria-labelledby 提供明确语义，子元素应为原生交互控件，禁止嵌套，键盘导航需手动实现焦点管理，并同步 ARIA 状态。
role="toolbar" 的语义作用和基本用法
它本身不提供任何样式或交互，只是告诉辅助技术“这里是一组相关操作控件”，比如按钮、下拉菜单、开关等的容器。浏览器不会自动添加键盘导航逻辑，也不会改变默认行为。
常见错误是直接套在 <div> 上就以为完成了——没配 aria-label 或 aria-labelledby，屏幕阅读器只会读成“工具栏”，用户完全不知道这是干啥的工具栏。
- 必须搭配可访问的标签：用
aria-label="编辑工具栏"或指向一个 visible 标题元素的aria-labelledby="toolbar-title" - 子元素应为交互控件：优先用原生
<button>、<select>、<input type="checkbox">，避免用<div role="button">堆砌 - 不要嵌套另一个
role="toolbar"：多层工具栏应拆成多个独立 toolbar，用视觉分隔（如 border 或 spacing）而非嵌套
键盘导航需手动实现 focus 管理
HTML 标准里 role="toolbar" 不触发 roving tabindex 行为。如果你希望按 Tab 进入工具栏后，用方向键切换按钮，得自己写 JS 处理焦点流。
典型场景是富文本编辑器顶部的格式按钮行——用户期望左/右箭头在按钮间移动，Home/End 跳到首尾，Enter 或 Space 触发操作。
立即学习“前端免费学习笔记（深入）”；
- 给所有可聚焦子项设
tabindex="-1"，仅第一个按钮设tabindex="0" - 监听
keydown事件，捕获ArrowLeft/ArrowRight，手动.focus()到相邻控件 - 注意跳过禁用项（
disabled或aria-disabled="true"），并循环到首/尾 - 别忘了处理
Shift + Tab退出工具栏的逻辑
与 CSS 和 ARIA state 的配合要点
视觉样式不影响语义，但混乱的布局会破坏工具栏的感知连贯性。辅助技术依赖 DOM 顺序和结构推断控件关系，CSS flex 或 grid 排列没问题，但绝对定位或 display: contents 可能打乱阅读顺序。
状态同步容易被忽略：按钮是否激活、是否选中、是否禁用，都要同步更新 aria-pressed、aria-checked、aria-disabled。
- 切换加粗按钮时，除了改 class，必须同步设
aria-pressed="true"（toggle button 场景） - 下拉菜单按钮要配
aria-expanded="true/false"，且展开面板需关联aria-controls="menu-id" - 避免仅靠颜色表示状态（如灰色 = disabled），必须有文字提示或图标补充
- 工具栏内若有搜索框，它本身应是
role="search"，而不是塞进 toolbar 里就完事
React/Vue 等框架中的常见疏漏
组件抽象容易掩盖 DOM 结构问题。比如封装一个 Toolbar 组件，内部用 Fragment 或 v-for 渲染按钮，结果真实 DOM 没有包裹容器，role="toolbar" 就挂空了。
另一个坑是动态渲染：按钮根据权限隐藏时，如果只用 v-if 或 && 条件渲染，会导致 DOM 缺失，工具栏内控件数量变化，但焦点管理逻辑没重置。
- 确保最终输出的 DOM 存在单一父容器，且该容器带
role="toolbar"和必要 label - 用
key控制列表项稳定性，避免焦点意外跳转；禁用项保留 DOM 节点（用visibility: hidden或aria-hidden="true"），而非移除 - 服务端渲染（SSR）时，若初始状态无按钮，客户端 hydrate 后才加载，要确保首次 focus 进入时 toolbar 已就绪，否则键盘导航失效
