HTML原生元素如button、a[href]、input等自带键盘语义，而div等容器无论tabindex如何设置均无默认键盘响应；自定义组件需同时满足可聚焦、正确监听keydown并preventDefault、添加role和aria-label三条件。
焦点导航和键盘操作不是一回事，但浏览器强制把它们绑在一起
HTML 中的「焦点导航」（focus navigation）本质是浏览器对 tabindex 层级、Tab 键顺序、Shift+Tab 反向跳转的一套内置调度逻辑；而「键盘操作」指用户按下的任意键（如 Enter、Space、方向键等）是否触发行为。二者在 DOM 层面被解耦，但在可访问性规范（WAI-ARIA）和浏览器实现中被强关联——比如一个 button 元素即使没写 onclick，按 Enter 或 Space 仍会触发其默认行为。
常见误解是以为“只要能 Tab 进去，就能用键盘操作”，其实不然：
• div 加了 tabindex="0" 后能获得焦点，但按 Enter 不会自动触发任何事
• input[type="checkbox"] 能 Tab 进入，且 Space 会切换状态，但 Enter 无反应
• 自定义组件（如用 div 模拟下拉）必须手动监听 keydown 并区分 Enter/ArrowDown 等键，否则键盘用户无法操作
哪些 HTML 元素自带键盘语义？看原生行为表
浏览器对部分元素硬编码了键盘响应逻辑，不依赖 JS 就生效。这不是“功能”，而是规范要求的行为：
-
button：响应Enter和Space（按下时触发click） -
a[href]：仅当有href时响应Enter（触发跳转），Space不响应 -
input[type="text"]、textarea：自动进入编辑态，方向键移动光标，Enter在textarea中换行，在单行input中可能触发表单提交 -
input[type="checkbox"]/radio：响应Space切换选中状态 -
select：响应方向键展开/切换选项，Enter确认
注意：div、span、section 等通用容器元素，无论加多少 tabindex，都不会自动响应任何键盘事件——这是最常踩的坑。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
自定义组件怎么正确绑定键盘行为？别只监听 keydown
给非原生控件（比如用 div role="button" 实现的按钮）加键盘支持，不能只写 addEventListener('keydown', ...) 就完事。必须同时满足三个条件：
- 确保元素可聚焦：设置
tabindex="0"（或tabindex="-1"配合 JS 主动.focus()） - 监听
keydown，但只处理特定键（如Enter、Space），并立即调用event.preventDefault()阻止默认行为（例如Space会导致页面滚动） - 兼容辅助技术：加上
role（如role="button"）和aria-label（或aria-labelledby），否则屏幕阅读器不会告知用户“这是一个可操作按钮”
示例（简化版）：
<div tabindex="0" role="button" aria-label="删除当前项">?️</div>
<script>
document.querySelector('div[role="button"]').addEventListener('keydown', e => {
if (e.key === 'Enter' || e.key === ' ') {
e.preventDefault();
handleDelete();
}
});
</script>
为什么用 keyboardEvent.code 而不是 key？
判断按键时用 e.code（如 "Enter"、"ArrowDown"）比 e.key 更可靠。因为：
-
e.key返回的是按键产生的字符值，受输入法、大小写锁定、键盘布局影响。比如美式键盘按右Shift+2得到e.key === "@"，但e.code === "Digit2" -
e.code始终表示物理按键位置，与当前输入状态无关，适合做导航控制（方向键、Tab、Enter 等） - 方向键、功能键（
F1–F12）、修饰键（Shift、Ctrl）只有code能稳定识别
所以键盘导航逻辑里，该用 e.code === "ArrowUp"，而不是 e.key === "ArrowUp"——后者在某些输入法下可能返回空字符串或错误字符。
真正难的不是写几行监听代码，而是想清楚：这个组件在键盘流里该扮演什么角色？它需要响应哪些键？是否要暴露给屏幕阅读器？这些决定了 tabindex、role、aria- 属性和事件监听的组合方式。漏掉任一环，键盘用户就卡住了。
