仅设 display: flex 不足以实现可访问导航，因它不控制焦点流、缺乏语义且无法同步状态；需结合 role="toolbar"、正确 HTML 结构、ARIA 属性及键盘事件处理。
直接给工具条容器设 display: flex 不足以支持键盘导航——它只解决排列，不解决焦点流、语义和状态同步。真正的可访问性工具条必须让 Tab 键能顺序进入每个控件，Enter/Space 触发操作，且屏幕阅读器能准确播报当前项状态。
为什么不能只靠 display: flex 实现可访问导航
Flex 布局本身不改变 DOM 焦点顺序，也不提供语义信息。常见错误包括：
- 把
tabindex="0"错加在ul或nav容器上，导致整组被当做一个焦点项，无法逐项操作 - 用
div替代button或a做工具按钮，丢失原生键盘行为（如Space按下触发） - 隐藏某项时仅用
visibility: hidden或opacity: 0，但未移除tabindex，造成“不可见却可聚焦”的陷阱 - 未设置
role="toolbar"和aria-orientation="horizontal"，屏幕阅读器无法识别这是工具条而非普通列表
role="toolbar" 必须配合正确的 HTML 结构
语义结构是可访问性的基础。工具条不是随便一堆按钮的堆砌：
- 外层用
<nav></nav>包裹，明确导航区域意图 - 内部用
<div role="toolbar" aria-label="编辑工具">，而非 <code>ul——因为工具条通常含混合控件（按钮、下拉、开关），ul语义仅适用于纯列表 - 每个可交互项必须是
button、a（带href）或带role="button"的元素，且有明确aria-label或可见文本 - 禁用状态统一用
disabled属性（对button）或aria-disabled="true"（对自定义元素），不能只靠样式灰掉 - 避免在工具项上设
outline: none，除非你用:focus-visible提供更优焦点样式；否则Tab用户将彻底“失焦” - 不要对工具项设
flex: 1，尤其当内容长度差异大时（如“保存” vs “撤销所有更改”），会导致文字换行或压缩，影响屏幕阅读器播报完整性 - 用
gap控制间距，而不是margin：避免最后一个按钮因margin-right出现额外空白，干扰焦点框视觉定位 - 移动端小屏下若折叠部分工具项，隐藏时必须同时设
display: none或visibility: hidden+aria-hidden="true"，否则仍可能被Tab访问到 - 监听
keydown时，先event.preventDefault()，再显式调用对应按钮的.click()或触发其逻辑，确保行为一致 - 状态切换（如加粗按钮高亮）必须通过
aria-pressed="true"而非仅改 class；屏幕阅读器只认 ARIA 属性 - 若某快捷键对应多个按钮（如格式刷可作用于文字/图片），需用
aria-controls指向目标区域 ID，并确保该区域有role="region"和aria-live（如需实时反馈） - 所有快捷键组合必须在工具项的
aria-keyshortcuts中声明，例如aria-keyshortcuts="Ctrl+B"，屏幕阅读器会主动提示
Flex 布局中控制焦点流的关键 CSS 实践
Flex 只管视觉排列，但需配合 CSS 防止意外打断键盘流：
立即学习“前端免费学习笔记（深入）”；
键盘快捷键与 ARIA 状态同步不能靠 JS 猜
工具条常需快捷键（如 Ctrl+B 加粗），但快捷键响应和 UI 状态必须严格同步：
最易被忽略的是：工具条一旦嵌入 iframe 或 Shadow DOM，Tab 流会中断，且 aria-keyshortcuts 在跨域 iframe 中无效。这类场景必须由宿主页面统一接管快捷键分发，并通过 postMessage 同步状态。
