HTML中无原生toolbar元素，须用配合aria-label或aria-labelledby实现语义化工具栏，仅role="toolbar"不满足可访问性要求，且禁止嵌套或混入导航链接。
HTML 没有 toolbar 元素或原生工具栏语义标签
浏览器标准 HTML 中根本不存在 <toolbar></toolbar>、<menubar></menubar> 或类似语义化“工具栏”区域的元素。所谓“定义文档工具栏区域”，实际是靠开发者用通用容器 + ARIA 属性 + CSS 布局来模拟。
常见错误现象：直接写 <toolbar><button>保存</button></toolbar>，结果页面无样式、无语义、屏幕阅读器无法识别——因为该标签不被任何浏览器解析为有效 HTML 元素。
- 必须用
<div>、<code><section></section>或<nav></nav>等合法容器包裹按钮/操作控件 - 通过
role="toolbar"显式声明语义，让辅助技术理解这是工具栏区域 -
aria-label或aria-labelledby必须提供可访问的名称，否则视障用户只知道“工具栏”，不知道是“编辑工具栏”还是“表格操作工具栏” - 正确写法：
<div role="toolbar" aria-label="图片编辑工具栏">...</div> - 错误写法：
<div role="toolbar">...</div>（缺失名称，WCAG 4.1.2 失败） - 如果工具栏内已有可见标题（如
<h2>格式工具</h2>），可用aria-labelledby="id-of-h2"替代aria-label - ❌ 错误：
<div role="toolbar"><div role="toolbar">...</div></div> - ❌ 错误：在 toolbar 里放
<a href="/home">首页</a>—— 导航应归<nav></nav>或role="navigation" - ✅ 正确：只放
<button></button>、<input type="checkbox">、<select></select>等可交互操作控件 - 确保 DOM 顺序符合操作逻辑（如“保存”在左，“撤销”在右，就按此顺序写 HTML）
- 给
button和可聚焦元素加:focus-visible样式，别依赖默认 outline（很多 CSS 重置会干掉它） - 避免用
tabindex="1"手动干预顺序 —— 容易破坏自然流，且在嵌套组件中极易冲突
用 role="toolbar" 时必须配 aria-label
只加 role="toolbar" 不够，ARIA 规范要求所有 role="toolbar" 元素必须有可访问名称（accessible name），否则会被屏幕阅读器忽略或报错。
使用场景：富文本编辑器顶部按钮组、表格上方的筛选/导出操作区、代码编辑器的运行/调试控制条。
立即学习“前端免费学习笔记（深入）”；
toolbar 不能嵌套另一个 toolbar，也不该放导航链接
ARIA 文档明确禁止 role="toolbar" 的嵌套，且它语义上代表“一组快捷操作控件”，不是导航结构。混用会导致语义混乱和键盘焦点逻辑异常。
性能/兼容性影响：某些旧版 NVDA 或 JAWS 在遇到嵌套 toolbar 时会跳过子项，或把整个区域读作“空白工具栏”。
CSS 布局要配合键盘操作习惯，别只顾视觉对齐
工具栏不是静态图片，用户要用 Tab 键顺序聚焦、用空格/回车触发、用方向键切换（尤其在 <select></select> 或分组按钮中）。纯 Flex/Grid 对齐不够，还得处理焦点流和视觉焦点样式。
容易踩的坑：用 display: flex; justify-content: space-between; 把按钮撑开后，Tab 键顺序仍是 DOM 顺序，但视觉上中间按钮看起来像“第二位”，用户预期却可能是“居中主操作”优先聚焦。
