键盘用户无法访问导航区，因默认不可聚焦且内部元素缺乏可聚焦性与语义属性；需确保链接合法、汉堡按钮为、多级菜单支持方向键与aria属性、保留可见焦点样式、统一输入方式处理及完整焦点流设计。
nav 里没加 tabindex 或 role，键盘用户根本进不去
很多页面用 <nav><ul><li><a href="/home">首页</a></li></ul></nav> 写完就以为 OK，结果键盘用户按 Tab 键直接跳过整个导航区。原因很简单：<nav></nav> 默认不可聚焦，<ul></ul> 和 <li> 也不是可聚焦元素。
必须显式让导航可进入：
-
<nav></nav>不需要加tabindex，但它内部第一个链接（或触发按钮）得是自然可聚焦的——确保<a href></a>有合法地址，别写href="#"或href="javascript:void(0)" - 如果主导航是汉堡菜单（移动端折叠态），触发按钮必须是
<button type="button"></button>，不能是<div> 或 <code><span></span>，否则无法通过空格/Enter 激活 - 下拉菜单的父项要加
aria-haspopup="true"和aria-expanded="false"，JS 切换展开时同步更新这两个属性 - 只有明确声明
role="menu"的容器（如<ul role="menu"></ul>）才应启用方向键逻辑；普通横向导航不用强加 menu role，反而破坏语义 - 子菜单
<ul role="menu"></ul>必须用aria-labelledby指向其父项的 ID，让读屏器建立父子播报关系 - 方向键处理只需监听
keydown，判断event.key是 ArrowDown/ArrowRight 等，并手动focus()到目标<a role="menuitem"></a>—— 不要试图拦截 Tab 键本身 - Esc 键必须关闭当前展开的子菜单，并把焦点移回触发按钮
- 所有可聚焦的导航项（
<a></a>、<button></button>）必须保留可见焦点样式。禁用 outline 前，先用outline-offset和box-shadow做等效替代 - 别写
*:focus { outline: none; }这种全局规则——它会一棍子打死所有可访问性焦点 - 高亮当前页推荐用
aria-current="page"，而不是靠 JS 动态加class="active"；前者语义明确，读屏器会主动播报“当前页面” - 如果用了 CSS-only 汉堡菜单（checkbox hack），注意 iOS Safari 在 checkbox 被 label 激活后，焦点不会自动落到菜单上——得用
setTimeout(() => menu.focus(), 0)补一脚 - 在
touchstart回调里不要直接调element.focus()，先event.preventDefault()阻止默认行为，再用setTimeout(() => el.focus(), 0)延迟执行 - 每次菜单展开，都要确保第一个可聚焦子项（通常是第一个
<a role="menuitem"></a>）获得焦点；收起时焦点应回到触发按钮 - 别依赖
:focus-visible做样式区分——Safari 直到 iOS 16.4 才支持，且在混合输入场景下检测不准；稳妥做法是用 JS 记录最近一次输入方式（pointerdownvskeydown），再动态加类控制 outline 显示
Tab 键只在 a 标签间跳，没法用方向键选子菜单
纯靠 Tab 浏览对多级菜单极不友好：用户得反复按 Tab 才能进二级项，路径长、易迷失。WCAG 要求支持方向键导航（↑↓←→），尤其对 role="menu" 结构。
实操要点：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
当前页高亮用了 class="active"，但键盘焦点轮廓被 CSS 吃掉了
很多人写了 a[aria-current="page"] { background: #007bff; color: white; }，却忘了重置默认的 outline。结果键盘用户按 Tab 到当前项时，什么视觉反馈都没有，完全不知道焦点在哪。
关键修复项：
移动端 touchstart + keyboard 导航混用时 focus 状态错乱
iPad 或 Android 平板上，用户可能既点触控又连键盘。这时常见问题：点开下拉菜单后，再按 Tab 键，焦点卡在按钮上不动，或者子菜单项无法被聚焦。
根源在于浏览器对触摸事件后的 focus 管理不一致：
最易被忽略的一点：键盘导航不是“加个 tabindex 就完事”，而是整套焦点流设计。从入口按钮、各级菜单项、到退出路径（Esc / Tab 循环 / 关闭按钮），每一步都得可预测、可逆、可播报。漏掉任意一环，对屏幕阅读器用户就是断路。
