tabindex="0"使元素进入标准Tab顺序，tabindex="-1"仅支持JS聚焦，禁用正数；需配合role和aria-*提供语义；按钮类交互优先用click事件；动态内容须主动管理焦点。
tabindex 属性怎么设才让键盘导航真正可用
不是所有元素默认支持 常见错误是给非交互容器加 光有 必须同步补全 ARIA 语义： 立即学习“前端免费学习笔记（深入）”； 漏掉任一属性，键盘用户可能无法理解操作意图，或操作后焦点丢失。 很多开发者监听 正确做法是： 单页应用里，路由切换、弹窗打开、列表筛选后，焦点常常“消失”——用户按 典型场景和对策： 焦点不可见、不可预测，是键盘导航最隐蔽的失败点——它不报错，但会让真实用户彻底卡住。Tab 键聚焦，只有原生可交互元素（如 、、）才有内置键盘导航能力。想让 参与导航，必须显式设置 tabindex，但值的选择直接影响行为：
tabindex="0"：元素进入标准 Tab 顺序，能用 Tab 进入，也能用 .focus() 编程聚焦tabindex="-1"：不能通过 Tab 到达，但可通过 JS 聚焦（适合模态框首次打开时手动聚焦主内容区）tabindex="1" 及正数：强制插入 Tab 顺序，极易打乱逻辑流，**强烈不建议**tabindex="1"，结果整个页面焦点跳转错乱，用户找不到“下一个该按哪”。role 和 aria-* 怎么配合 tabindex 构建语义化导航
tabindex 不够。屏幕阅读器需要知道这个可聚焦元素“是什么、能干什么”。比如一个模拟下拉按钮的 tabindex="0"，读屏软件只会念“空白”，不会提示“下拉菜单，按空格展开”。
role="button" 告诉辅助技术这是个按钮aria-expanded 动态反映展开状态（JS 中需同步更新）aria-haspopup 暗示有子菜单，触发后应把焦点移入列表
键盘事件监听为什么不能只绑 keydown
keydown 处理回车/空格触发点击，但忽略了一个关键问题：某些键盘组合（如 Shift+Tab、Ctrl+Tab）会绕过你的监听，直接由浏览器接管。更严重的是，keydown 会捕获所有按键，包括输入法上屏前的拼音键——导致中文输入被意外中断。
click 事件（它天然兼容空格/回车触发）keypress 或 keyup，并检查 event.key 是否为 "Enter" 或 " "（空格）if (event.isComposing) return 阻止输入法干扰焦点管理在动态内容中容易被忽略的点
Tab 从上一页残留位置继续走，而不是落到新内容起点。这不是 bug，是没做主动焦点管理。
element.focus() 聚焦第一个可交互项，同时用 inert 或 aria-hidden="true" 隐藏背景区域（防止焦点逃逸）tabindex="-1"，再 .focus()
popstate 后，聚焦到 main 区域或 h1，别让用户从顶部重新 tab 十几次
